NOTE: I am on the product marketing team at CockroachLabs.
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.