View all

Most software projects start their lives linked to a simple, single-instance database. Something like Postgres or MySQL. But as companies grow, their data needs grow, too. Sooner or later, a single instance just isn’t going to cut it. That’s where data partitioning comes in.

Charlie Custer

February 7, 2023

If you’re building and managing applications in public cloud providers like GCP or AWS, chances are you’ve heard of VPC peering. This blog post explains what VPC peering is, why you’d want to use it, and, if you’re using CockroachDB Dedicated today, how you can get started with our VPC peering functionality.

Tommy Truongchau

February 2, 2023

We are thrilled to announce that CockroachDB Dedicated, the fully managed service of CockroachDB, is now PCI-DSS certified by a Qualified Security Assessor (QSA) as a PCI Level 1 Service Provider. The PCI-DSS was created by the PCI Security Standards Council - an organization formed in 2006 by the major credit card associations (Visa, American Express, MasterCard and JCB). The mission of this council is to establish a “minimum security standard” to protect customers’ payment information. Any business that handles credit card and payment data is required to conform to that minimum standard referred to as the Payment Card Industry (PCI) Data Security Standard (DSS).

If you’re working with CockroachDB, chances are that you care about transactional consistency. CockroachDB offers ACID transactional guarantees, including serializable isolation to ensure that no matter the volume of transactions or how many transactions are being processed in parallel, each transaction is committed to the database sequentially. These guarantees ensure that your database maintains ironclad consistency immediately, which is important for many transactional applications. (Every application has a range of business use cases that determine how consistent its database needs to be. For transactional workloads, an eventually consistent database is often not the right persistence tool). However, CockroachDB’s strong ACID guarantees do mean that occasionally transactions will fail and will need to be retried. Let’s take a closer look at why that happens, and how retries can be accomplished.

Charlie Custer

January 30, 2023

One mistake that should never be made is to assume permissions and identity access are easy. If you plan on just throwing some rows in the database and then making an authorization decision based on the existence (or nonexistence) of a row… then you might not be “secure”. And further, once you are successful, you should also start to consider a scalable and more accurate approach.

Cassie McAllister

January 26, 2023

Any enterprise-grade database needs to have a mature story when it comes to Backup and Recovery. Historically, due to architectural limitations, many relational database technologies relied heavily on backups in the event of a disaster (they use backups to recover data to a secondary location for Disaster Recovery). Technology has advanced over recent years, driven mainly by the hyper scalers. The introduction of Read Replica standby nodes, which are distributed over multiple locations and are ready to take over if the primary node fails, has increased the resilience of these solutions. These can be spread over multiple locations. In this blog, I’ll demonstrate how to do this with CockroachDB and Azure blob.

CockroachDB relies heavily on multi-version concurrency control (MVCC) to offer consistency guarantees. MVCC, by design, requires the database to keep multiple revisions of values. A buildup of these revisions can impact query execution costs for certain workloads. In this article, we introduce the idea of Protected Timestamps: a novel way for CockroachDB to efficiently retain only relevant revisions, while safely deleting (garbage collecting) old ones.

Bulk ingestions are used to write large amounts of data with high throughput, such as imports, backup restoration, schema changes, and index backfills. These operations use a separate write path that bypasses transaction processing, instead ingesting data directly into the storage engine with highly amortized write and replication costs. However, because these operations bypass regular transaction processing, they have also been able to sidestep our normal mechanisms for preserving MVCC history.

This is part 3 of a 3-part blog series about how we’ve improved the way CockroachDB stores and modifies data in bulk (here is part 1 and here is part II). We went way down into the deepest layers of our storage system, then up to our SQL schema changes and their transaction timestamps - all without anybody noticing (or at least we hope!)