Is there something I am missing? Why would someone simply switch their backed databases for something that does not even offer Data Warehousing or other data management tools?
CockroachDB is well suited for applications that require reliable, available, and correct data, and millisecond response times, regardless of scale, and belongs to the category of NewSQL, which promises to combine benefits from RDBMS (strong consistency) with benefits from NoSQL (scalability); it mainly achieves this through new architecture patterns and efficient SQL storage engines. TiDB and CockroachDB are a few of the leading NewSQL databases. Each database implementation has its own take on how to ensure strong consistency with a scalable architecture.
The following situations are some hints you may consider for a switch,
1. RDBMS is becoming the performance bottleneck of your backend service
2. The amount of data stored in the database is overwhelming
3. You want to do some complex queries on large amount of data that cannot fit in one machine without manual sharding
4. Your application needs a full ACID transaction for data distributed on multiple machines.
There are multiple choices for NewSQL too, engineers are always trying to compare TiDB and CockroachDB, here’s some considerations before you decide.
TiDB is compatible with the MySQL protocol while CockroachDB is compatible with PostgreSQL. You can directly connect to TiDB server using any MySQL client and benefit from the MySQL ecosystem. Plus TiDB is well adopted and trusted by 1000+ large scale Internet companies and banks.
Currently, CockroachDB is not suitable for Online Analytical Processing (OLAP) while TiDB is a Hybrid Transactional and Analytical Processing (HTAP) database that supports both OLTP (Online Transactional Processing) and OLAP workloads. So with TiDB, a typical ETL (Extract, Transform and Load) process that moves data to a different database for analysis is no longer required, enabling you to create new values for your users, easier and faster.
Hope the above can help you a bit.
I have a feeling these technologies will be much more mainstream in 2-3 years
Indeed! With the current situation going on, the digitalisation accelerated, and the dataset is moving to a large scale, we see a huge demand of services like this.
Write replication requires external products.
Pairing that with edge compute like fly.io is a killer combination. That you can use most of your normal Postgres libraries with it make it an easy transition.
Tokyo - NYC is ~175 ms and that’s a good route. Compound that by all the requests you app does.
Cockroach Labs has been building CockroachDB for over five years and has reached a level of maturity where many enterprise and community customers are gaining value from the database.
We consider it a cloud-native database as it was architected with the same principles as a distributed platform like Kubernetes. It is built for scale, resilience, is shared-nothing and is comprised of a single binary across all nodes with consistent API. We have also gone to great lengths to ensure it is wire-compatible with PostgreSQL and implements a large portion of standard SQL syntax. \It is used as a relational database.
The key points we typically talk about fall into four key areas, that we lovingly refer to as CRLS (an acronym for Cockroach Labs)
Consistency - the database implements serializable isolation across distributed nodes within a cluster with acceptable latencies even both local and globally dispersed deployments.
Resilience - the database replicates data across nodes in the cluster and you can configure this to survivability at the table level for optimization of a loss of a node, zone or even region. It is an active-active system that is always on and data is always available. Further, you can implement online schema changes and rolling upgrades in production without downtime,
Scale - scaling the database is accomplished by simply spinning up a node and pointing it at the cluster. The database will take care of redistributing replicas to incorporate the new node. This is basically auto-sharding and adheres to the aforementioned policy of survivability mentioned above.
Locality - Unique to CockroachDB, you can also tie data to any particular node in the cluster. You define this at the table level. The database uses KV at the storage layer to accomplish this. Each table is represented as ordered KV pairs using the PK for the table for the Key. You work the location into the key and the distribution policy will ensure data is written to explicit nodes. This is used to ensure low latency access of data and/or to tie data to a location for compliance and privacy requirements. With online schema changes, you can manipulate the PK in production and rearrange where data is physically stored in a live production cluster.
There are numerous other capabilities in the database. We have a complete UI, deliver distributed backup/restore, change data capture and have implemented a cost-based optimizer that uses locality.
It is a relational database that you can deploy the database as a service on kubernetes and or in any cloud.
There are countless more capabilities and we invite you to check out one of our features we are most proud of… our documentation!
Also, please check out customer page - yes, these are high level but there are some stories there.
Are they getting adoption? And what's their unique value proposition?
It think you mean “who cares, if it works well?”. Or, if you don't want that much disambiguating load being held up by a comma, “if it works well, who cares?”
The creature it refers to pretty universally considered repulsive. I'm no psychologist or anything, but I would expect that to have an undue influence on even the most rational person.
It will definitely not help any CIO or anyone in an organization who tries to lobby for their org to adopt cockroach db.
I don't know what he means by "data management"
[1]https://www.cockroachlabs.com/docs/stable/frequently-asked-q...
Compared to Cockroach DB which seems like a niche SQL replacement?