How does your infrastructure look like? Do you deploy it in a single datacenter or even in the same rack on a couple of servers?

Are you using enterprise ? If not how are you handling backups?

ScyllaDB is still the fastest at a key/value workload with per-query consistency settings and quorum reads/writes across multiple regions. If you need high-performance and low-latency, ScyllaDB wins. They are close to v3.0 which will have global secondary indexes and materialized views to improve data model flexibility. FoundationDB is also key/value but much lower-level and well proven for reliability. Don't have much experience with it and the latest release just introduced multi-regional capabilities, but the general tooling and documentation is still rough and it would take more effort to build a higher-level querying layer or client library.

TiDB is interesting, but missing more features from MySQL than CRDB is missing from PostgreSQL, so it's effective if you want sharding on mysql but will need a few more releases before it gets polished. Vitess and Citus are good options if you just want sharding on top of existing mysql or postgres with full query support within a shard. There's also Yugabyte which is multi-modal Redis/Cassandra/SQL offering with multi-regional capabilities.

CRDB is a great product with some of the easiest operations (although key management is a nightmare that they do not have a good plan for). It's fast enough for point-lookups and makes it easy to distribute and replicate your data across zones and regions. All nodes are part of a single cluster so read and write latencies will be high for global deployment, with the enterprise version having a workaround for local regional reads using pinned covering indexes. That works, but further lowers write performance.

It also has trouble with large transactions and the middle ground between OLTP and OLAP with heavy joins. Good choice if you need easy scalability and SQL interface over performance and complex queries.

I'm the author of the post.

1. Between 90 and 135 16 vCPU nodes depending on cloud hardware 2. The cluster replicates this data three ways across all three nodes (so the cluster actually contains 12+tb of data) ensuring high availability. We intentionally reported the unreplicated number for clarity and comparison to TPC-C spec 3. Our graph is mislabeled. It should read transactions per second `tps`. Nice catch! 4. We can't comment on other database performance as they haven't release any TPC-C numbers.

I'm the author. We've introduced transactional write pipelining (covered in a forthcoming blog post), load-aware rebalancing, and completed general performance tuning which all contribute to our improved performance numbers.

We have clients using CRDB in pretty constrained environments, and they use it primarily because of the easy administration. I think you'll find it easier to use than a MySQL or Postgres, for example.

I would expect your use case would be better suited by use just using postgres. However if you do need to scale to the point where you'd need to distribute your database and take advantage of CRDB's capabilities, it uses the Postgres protocol, so you most likely can just migrate your data and use the same code.

Sqlite would be my first recommendation, unless you need client/server access.

What do you mean "strict seralizability has its limitations", you need something stricter? Or you have a need for something weaker for some reason?

Why as an alternative to vitess? Are you hitting limits with vitess?

Not an easy benchmark..

We released a managed version at the end of October, with auto-scaling, geo-replication, etc. --> https://www.cockroachlabs.com/product/managed/

Not sure that there any books on it yet.

you know what's ironic? that in every thread there's one of you people complaining about the name - you're all just like cockroaches! no matter how successful cockroachdb becomes, no matter how technically impressive the product becomes, the naysayers never die.

can you imagine 20 years ago someone complaining that google wasn't safe for work because it had a silly name?

newsflash dummy: stop saying/thinking/repeating stupid things like this and it'll stop being the case that everyone is so conservative that silly names are inadmissible.

That's the idea though — your data will be hard to kill.

In their presentation they have it abbreviated as CRDB, so that might be a viable direction without pain.

> known by eating almost everything and living almost everywhere

Good attributes for a DB though?

I have to admit, the name does set me on edge slightly. shudder