This is a great post byu Andy Kimball on what they mean when they say CockroachDB is now serverless:

Serverless means you don’t have to think about servers. Of course there are servers hard at work handling your application’s requests, but that’s our problem, not yours. We do all the hard work behind the scenes of allocating, configuring, and maintaining the servers. Instead of paying for servers, you pay for the requests that your application makes to the database and the storage that your data consumes.

How they got here:

Before now, a single physical CockroachDB cluster was intended for dedicated use by a single user or organization. That is called single-tenancy. Over the past several CockroachDB releases, we’ve quietly been adding multi-tenancy support…

How they scale it:

Within every Serverless cluster, there is an autoscaler component that is responsible for determining the ideal number of SQL pods that should be assigned to each tenant, whether that be one, many, or zero.

And what it all means for Cockroach’s users.

There was a discussion in Slack today about the recent Postgres episode on The Changelog and a mention of considering CockroachDB in order to be distributed-by-default and Postgres compatible. But why is CockroachDB Postgres compatible? Here’s a breakdown from Ben Darnell, CTO and Co-Founder of Cockroach Labs…

CockroachDB is built to be largely compatible with PostgreSQL, meaning that software written to use PostgreSQL can sometimes (often!) be used with CockroachDB without changes.

Initially, CockroachDB toyed with the idea of compatibility with MySQL. What tipped the balance in PostgreSQL’s favor was a combination of multiple factors. There was initially a clear impression that PostgreSQL’s documentation of its network protocol was clearer, more detailed and overall more supportive of a third party implementation than MySQL’s documentation of its own protocol.

This is a nice lessons learned post from one engineering team making a database switch.

Overall, I’m happy with how the effort turned out and with CockroachDB in general. Because it uses PostgreSQL’s wire protocol, existing PostgreSQL drivers should work as-is. But we did run into some challenges that are worth pointing out. Here’s a list of things you might want to consider…

I like the update at the end, which emphasizes the important of tests for making a switch of this magnitude:

The system that was migrated has solid tests and good coverage. While a lot of the differences we ran into are obvious (like lack of range types and triggers), others were more subtle (especially the odd on conflict behavior). Test coverage made a pretty significant impact in the speed of the migration and our confidence in pushing live.

The co-founders of CockroachDB — Peter Mattis (CTO), Ben Darnell (Chief Architect), and Spencer Kimball (CEO) — co-wrote a post explaining their move to MariaDB’s Business Source License (BSL) in order to thwart competitors, otherwise know as “highly-integrated providers,” from offering a version of CockroachDB “as-a-service” without purchasing a license to do so.

We’re witnessing the rise of highly-integrated providers take advantage of their unique position to offer “as-a-service” versions of OSS products, and offer a superior user experience as a consequence of their integrations.

Here’s the tl;dr of this license change:

Today, we’re adopting an extremely permissive version of the Business Source License (BSL). CockroachDB users can scale CockroachDB to any number of nodes. They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license.

In this post, we highlight how CockroachDB 2.0 enables your data layer to evolve with your business: JSON enables rapid iteration in response to changing customer requirements; major throughput and scalability improvements help you handle huge increases in user request volumes; and a groundbreaking toolkit for managing multi-regional workloads lets you deliver low-latency applications to customers anywhere in the world.

Lots to ingest here. Also listen to Go Time #73 all about CockroachDB. 👇

Andrei Matei joined the show and talked with us about CockroachDB (and why it’s easier to use than any RDBMS), distributed databases with Go, tracing, and other interesting projects and news.

What do you use when your app needs to provide speed and availability to a global audience?

You need a distributed database that…

• Deploys anywhere
• Reduces latency by performing reads and writes close to users (while still enforcing consistency, even across a distributed deployment)
• Maintains uptime by tolerating faults
• Offers granular control over geographical placement of your data for GDPR compliance

Sounds like a CDN.

Kelsey Hightower joined the show to talk about the work he’s doing at Google Cloud Platform, Kubernetes, Bringing Pokémon GO to life on Google Cloud, Kubernetes cluster federation, Containers, and of course Go.