CockroachDB is an excellent system of record, but no technology exists in a vacuum. Some of our users would like to keep their data mirrored in full-text indexes to power natural language search. Others want to use analytics engines and big data pipelines to run huge queries without impacting production traffic. Still others want to send mobile push notifications in response to data changes without doing the bookkeeping themselves.

As we’ve written about previously, geographically distributed databases like CockroachDB offer a number of benefits including reliability, security, and cost-effective deployments. We believe you shouldn’t have to sacrifice these upsides to realize impressive throughput and low latencies. That’s why we created geo-partitioning. This blog post defines two new features, geo-partitioning and archival-partitioning, as well as explains when you might want to leverage these features. We previously provided a sneak-peak walkthrough of geo-partitioning that can be found here.

\* *This blog from 2018 does not represent the most recent strategies for pinning data to locations at the row level in CockroachDB. And certain capabilities referenced, like interleaving, are no longer supported. This documentation about our multi-region capabilities is the best place to begin learning about the current best practices for scaling your database across multiple regions: https://www.cockroachlabs.com/docs/stable/multiregion-overview* ```

Consistent, Distributed, Incremental Backup: Pick Three Almost all widely used database systems include the ability to backup and restore a snapshot of their data. The replicated nature of CockroachDB’s distributed architecture means that the cluster survives the loss of disks or nodes, and yet many users still want to make regular backups. This led us to develop distributed backup and restore, the first feature available in our CockroachDB Self-hosted offering.

CockroachDB is a distributed SQL database built on top of a transactional key value store. We don’t (yet) expose the kv layer but it’s general purpose enough that we’ve used it to implement SQL without any special trickery. The particulars of how we represent data in a SQL table as well as the table metadata are internally called the “format version”. Our first format version was deliberately simple, causing some performance inefficiencies. We recently improved performance with a technique called column families, which pack multiple columns in one kv entry.