Ask HN: How does YugaByte compare to CockroachDB (or just plain pgsql)? | Hacker News Reader

Ask HN: 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)?

View on HN

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...

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.

Thank you! Any data points are better than none!

Definitely. There is very little talk/discussion about these databases apart from evangelist articles. That's another reason for me to be hesitant to migrate. Still have a ping/alert whenever someone mentions these databases on HN.

(YugabyteDB Developer Advocate here)

@flagged24 If you can send me more info about your migration problems, I would love to look at it (fpachot@yugabyte.com). The postgres-compatibility, performance, and YB Voyager are improving from feedback.

The default parameters may not be the best to try an existing app. Here is a docker image I've made with the best defaults for a quick start: https://github.com/FranckPachot/yb-pglike to check the compatibility, and then look at more tuning.

@gunapologist99 I'm not a big fan of benchmarks, especially on products with fast evolution. The best is to test with something that is similar to your app and open an issue (github, forum, slack) if it is slow to be sure it's not a configuration issue, or bug recently fixed.

Franck

Thanks, will do when I give it another try.

TL;DR: you need to study both to get your best (performance-)results. These "serverless" or multi-server (and attempting multi-location) databases may well be the next wave of databases. CRDB and YB: They both take a postgres (or wire compatible ;-) front-end and Rocks-db storage behind that. Both also seem to prefer DBaaS rather than DIY-deployment. Last summer, I did brief few weeks of testing of both. For curiosity, not for performance. Both seem easy to deploy on servers or as containers/pods etc.. For Efficiency (performance), Especially for Yugabyte, you Need to Know a little about their sharding. If doing default initial deploy, just dump + ingest (?) will generally give you un-favorable storage for any smalll-ish table. Mainly bcse YB seems to assume you need Everything Sharded Everywhere (their storage mechanism seems to favour single-large-table models). Resilience wise, both are good, but again, you should know a little about their engineering to get Good Benefits. In all cases, bcse the "distributed" nature: Latency is probably going to be your Main Enemy.

Reply on news.ycombinator.com