Hacker News new | past | comments | ask | show | jobs | submit login

TiDB is mysql-compatible, written in Go, and runs on top of TiKV which is a custom key/value store written in rust. It's rapidly developing and serves well for a horizontally scaled simpler OLTP workload. It can handle OLAP queries better than CRDB but neither are great at it. It also has more moving pieces with the placement driver, TiKV and TiDB layers so install is harder.

Yugabyte is a proprietary C++ document-store engine called DocDB running on top of RocksDB. It offers access in multiple APIs with Redis, Cassandra CQL and now PostgreSQL. Dataset can only use a single API so you pick when creating each one. The PG part is getting the most focus right now and is very capable since it takes the planning part from PG itself. Supports more advanced queries than CRDB. More moving pieces again with a separate Master and Tablet layers. Great UI with cloud integration and multi-regional management built in. Also recently made all enterprise features free for open source too.

Citus is an extension, basically an automatic sharding system for PG that works across servers. It's bottlenecked on a single master node working with multiple workers but there's an experimental branch called Citus MX to make every node master-capable. Since all servers are just running PG, you have all the expected functionality and extensibility. All normal tables in a database live on the master (which can be limiting) and only "distributed" tables will be stretched across worker nodes. If you have a good scheme for sharding (like TenantID) then all data for tables sharing the same shard key can live on the same server and get 100% query functionality. Distributed SQL queries are not as good and can have strange failures. There was big recent update to improve this but you will have issues with very complex queries and joins. Interesting use-case for OLAP workloads that need OLTP like updates with indexes and constant writes. Microsoft uses this for a project and now owns the company so its available on Azure.

No experience with NuoDB but another mention is MemSQL for a distributed relational data warehouse that has a unique in-memory rowstore and on-disk columnstore model for fast OLTP and OLAP query support. The best support for complex SQL out of all of these and will probably run anything you send it. MySQL compatible and one of the most polished database products. It's expensive and proprietary although now has a free limited community edition, but extremely fast for analytics while maintaining usability.




Impressively informative! Regarding the install/deployment about TiDB, we have build tools such as open-source tools such as TiDB-Ansible for on-prem and TiDB-Operator for kubernetes. Here is a list of deployment instructions:

Ansible: https://pingcap.com/docs/dev/how-to/deploy/orchestrated/ansi...

Kubernetes (using TiDB-Operator): https://pingcap.com/docs/dev/how-to/deploy/orchestrated/kube...

Terraform on AWS: https://github.com/pingcap/tidb-operator/tree/master/deploy/...

Docker: https://pingcap.com/docs/dev/how-to/deploy/orchestrated/dock...

Binary: https://pingcap.com/docs/dev/how-to/deploy/from-tarball/prod...


Adding on: there's also Vitess for anyone looking for automatic sharding for MySQL. It's not an extension but works as as middleware that operates mysql instances for you and has great support on Kubernetes. Lots of big companies as users and originated from Youtube. The system is written in Go and has unique features like table materialization and resharding ability.


Vitess is far too complex to run imo unless you want to become a vitess-admin. We tried it for good 6-weeks to get a working PoC and moved to CRDB and had one working in hours.


Curious how/why you know what seems to be pretty esoteric knowledge/experience?


It's all personal experience and research from using these database products. I've also talked to the devs for each one, including here on HN sometimes.

What's esoteric about it though? I consider this to be standard knowledge if you're going to be investing into a database.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: