Product

CockroachDB offers a number of powerful enterprise features, most notably those related to geo-partitioning tables. Geo-partitioning allows users to control where their data lives geographically, at the row-level. To make geo-partitioning easier for users to try out, we made some updates to cockroach demo that enable you to check out enterprise features without the need for a full deployment. Note that all of the features discussed in this blog will be available in CockroachDB version 19.2. When you run cockroach demo in a terminal, CockroachDB starts a temporary, in-memory cluster, and then opens a SQL shell to that cluster. The in-memory cluster persists only as long as the shell is open, and the data is lost once the shell is closed. cockroach demo also automatically acquires a temporary enterprise license for each demo session, so you can use enterprise CockroachDB features right now. After you install CockroachDB, no further set up is necessary. So let’s dive right into the new features available for use with cockroach demo!

Our latest CockroachDB Feature of the Week, core changefeeds, is an exciting new way for event-driven apps to consume data from CockroachDB. With the CHANGEFEED FOR statement, a SQL client can tell the database to monitor a table and tell it when writes take place. CockroachDB will then hold the connection open until the client closes it and stream records to the client for all writes. You can use changefeeds to build event-driven applications, perform data integration, and do all kinds of other tasks that depend on watching the state of a table.

Roland Crosby

July 30, 2019

Since the 2.1 release, CockroachDB has had a cost-based optimizer. Rewriting a big component of an existing system is always challenging. In particular, we really wanted to avoid regressing on any workloads, including simple transactional queries where the existing planner was already generating the best plan. A cost-based optimizer inherently does more work and thus involves longer planning times. To mitigate this, we worked on caching and reusing optimizer state across multiple instances of the same query. For now, we chose a conservative path: only cache state from which we can still generate the best plan (the one we would have generated without caching), making caching invisible to the user. We’ll start with an overview of the stages of the query planning process; then we’ll go over the methods clients can use to issue queries against CockroachDB, and finally we’ll discuss the caching work we have done to speed up query planning.

Everybody loves a fast query. So how can we make the best use of the existing information to make joins on sorted data faster? The answer is lies in vectorizing the merge join operator. Today we’ll be looking into what a merge joiner is (or what it used to be), followed by what vectorization means and how it changes the problem, and ending with how we decided to make the merge join operator faster and what this means for your queries.

It’s been a little over four years since we started our mission to deliver an enterprise-ready distributed SQL database. Today, we’re excited to release CockroachDB 19.1. With this release, we enhanced distributed SQL capabilities, and expanded upon enterprise-grade features for security and data integrations. 19.1 continues to solve the challenge of complex, distributed SQL while meeting all the “enterprise” requirements that are expected of a database. Here’s Nate Stewart, our VP of Product, with a quick intro on what you can expect in CockroachDB 19.1. And for a deeper tutorial with Nate, register for our CockroachDB 19.1 webinar.

One small step for Cockroach Labs, one giant leap for our release numbering. Since our initial launch, Cockroach Labs has used semantic versioning in our release cycle guidelines. Two years, one major release, and n-patch fixes later, we're making the switch to Calendar Versioning. This means subscribers to our release notes will see quite the jump in today's version numbering, from last week's 2.1.5 to today's 19.1 beta.

Peter Mattis

February 25, 2019

CockroachDB was built to help teams scale their applications across the globe without sacrificing SQL’s convenience, power, and data-integrity guarantees. In CockroachDB 2.1, we’ve made it easier than ever to migrate from MySQL and Postgres, improved our scalability on transactional workloads by 5x, and launched a managed offering to help teams deploy low-latency, multi-region clusters with minimal operator overhead.

Nate Stewart

November 1, 2018

This week we’re pleased to announce the availability of Managed CockroachDB, the fully hosted and fully managed service created and run by Cockroach Labs that makes deploying, scaling, and managing CockroachDB effortless. Managed CockroachDB is cloud agnostic and available at launch on both AWS and GCP. The goal is simple: allow your development team to focus on building highly scalable applications without worrying about infrastructure operations.

Spencer Kimball

October 30, 2018

CockroachDB makes it possible to support a global customer base while remaining compliant with data privacy regulations. Operators interact with a single logical control plane that they can use to define how they want CockroachDB to store their row-level data. Meanwhile, developers continue to interact with our PostgreSQL-compatible API that transparently handles distributing queries across a global cluster. With our 2.0 release, we introduced a new cluster visualization in our web UI to help operators monitor a global cluster.