This is the post someone didn't want you to find, or read. It was deleted from its original location, and I had to go to the internet archive to find it.
It's worth reading the original, even though the images didn't make it to the archive. I'll summarize here though for those that want the TL;DR.
You're scaling to 100 million inference calls daily, your database is melting under a 22-terabyte workload, and AWS RDS architects are literally telling you "gosh, you guys are in big trouble" while offering zero solutions. That's exactly what happened to Cursor's engineering team when they tried to get clever with YugabyteDB.
The punchline? After a catastrophic 10-hour incident that nearly killed their indexing system, they moved the workload to plain old PostgreSQL on RDS. Result: "It works like a charm."
The author of the post, then goes on to talk about how distributed SQL solves problems you probably don't have and throws the whole distributed SQL space out because of their problems with a single (not every ethical) vendor in the space.
I'd argue, briefly, in defense of distributed SQL and point out that even Gartner has broken it out as its own category. You can read more about that here if you have a Gartner subscription. Of course Gartner's consensus is that besides CockroachDB and Google Spanner, it's slim pickings if you want a quality solution.
Compatibility isn't the same as reliability
Cursor's team thought they were being smart. YugabyteDB promised infinite scale with PostgreSQL compatibility. What they got was a database that "just wouldn't run" despite paying substantial money and scaling down as much as possible.
The lesson? Compatibility isn't the same as reliability. Moving to actual PostgreSQL on RDS solved their problems instantly.
The team at Cursor went back to Postgres with Amazon RDS, which is fine if you want a single writer, limited region support, and no ability to run on-prem or hybrid. You do get very good Postgres compatibility with Amazon RDS, with the tradeoff being manual downtime for some maintenance operations.
Frankly, after reading (and re-reading) the article it sounds like the Cursor guys are just really angry at Yugabyte for over-promising and under-delivering. Which is sorta on-brand for them, so not sure why the surprise.
I mean, here's a recent report where in order to out-perform CockroachDB they benchmarked their current release against a four-year old release of CockroachDB. They literally call it a new benchmark, and use version 21.2 of CockroachDB, released in November of 2021. Unethical? Likely. Disingenuous? Absolutely.
If you'd like to explore distributed SQL from an ethical company, one that delivers on its promises, why not get started with the free education offered at Cockroach University?
And, again, please read the original article that they didn't want you to find.