HACKER Q&A
📣 gunapologist99

How does YugaByte compare to CockroachDB (or just plain pgsql)?


The only things I can find are the dueling banjos on their respective websites and it looks like they've both done some significant performance improvements recently.

Has anyone not affiliated with these two companies compared them and have real numbers for e.g. latency or qps for various workloads? Even audited tpc is something.

What are the performance or management (such as backup/restore, alter tables, extensions, etc) tradeoffs compared to regular pgsql (sharded or not)?

  👤 fastest963 Accepted Answer ✓
We compared CockroachDB and YugabyteDB several years ago and had consistently better performance with YugabyteDB. We recently migrated our workloads from self-hosted to YugabyteDB Managed and have been happy. We do thousands of queries per second with less than 5ms latency. I would say the biggest problem we've had is managing Postgres connection memory usage but the Yugabyte team is working on a server-side proxy similar to pgBouncer but without the same limitations [1]. We're also awaiting the release of CDC that doesn't require us to run Kafka. While for other companies Kafka might already be a dependency in their stack, it's not for us and we'd prefer not to introduce it just for CDC.

Their Managed platform handles backup/restore, encryption, SSL, metrics, upgrades, and one-click scaling. You can even configure multi-region clusters with read replicas. Their platform is not very flexible with compute, however. You have fixed CPU and RAM sizes to choose from.

Happy to answer specific questions.

[1] https://docs.yugabyte.com/preview/explore/connection-manager...

👤 flagged24
I once tried both of these databases with an existing PostgreSQL database. I was never able to convert my pg database to YugabyteDB, YugabyteDB Voyager (a migration tool) would choke during the conversion/migration. I did manage to get a working CockroachDB version but had to drop quite a bit of features and consistency checks. I remember not being impressed with the added latency. Lessons learned: don't migrate existing projects to these distributed databases and only use them in new projects when you are in dire need of a distributed database and are comfortable with the added latency. Mind you, this was quite some time ago, I'm sure things have improved.