After writing my last article about Next Gen databases, I wanted to dig into CockroachDB and all it had to offer. It seemed like such an interesting new technology to me. I had heard of them before but never put aside the time to dive in and see how it would plug into my current favorite techstack so I thought I'd give it a shot.

I'll go through what CockroachDB is, why I thought it was so interesting, how my experiment ended up working out, and any drawbacks I encountered. So lets jump in!

What is CockroachDB and CockroachDB Serverless?

CockroachDB

CockroachDB is an open-source NewSQL database with the idea of bringing some benefits of NoSQL to the SQL world. Simple explained as,

It scales horizontally; survives disk, machine, rack, and even datacenter failures with minimal latency disruption and no manual intervention

The motive for this is that older SQL databases are not cloud-native in the sense that they don't have distributed architectures and are therefore not built for a node in a cluster going down. Additionally, this type of distributed architecture fits in well to the serverless paradigm of modern architectures.

CockroachDB Serverless

While CockroachDB is an open-source technology that can be self-hosted anywhere, the creators founded Cockroach Labs to offer cloud hosted solutions with it. From this, they created CockroachDB Serverless which is currently great for starting projects. It allows for auto-scaling that can scale-to-zero and consumption based billing. This means you can have a serverless and distributed database for free while keeping the power of SQL (typically these free / inexpensive solutions only exist for NoSQL databases).

Why CockroachDB Serverless is amazing

I honestly haven't been so excited to try a new technology in a while. I definitely favor SQL to NoSQL but always get annoyed as it's typically the last remaining static piece to a serverless architecture. While NoSQL is great for certain projects, it's non-relational schemas typically cause issues for me as the application (and therefore the data model) grows in complexity. With that being said, lets dive into why I was impressed with the offering.

Easy to setup

To start, setting up a database was almost too easy. I just needed to signup for an account with no credit card needed. That means I don't have to worry about eventually getting a bill when trying it out (and eventually using it for proof of concepts). After the database was created for me, they had great documentation for how to connect with many different options (command line, connecting string, and generic parameters). I had no issues with connecting to it with SQLAlchemy and running automated database migrations.

Inexpensive

Not only is it inexpensive, it's FREE up to a certain about of throughput and storage. This is amazing for starter projects as the database was always the last static piece in my architecture and would be the main cost to starting a projects with a more complex data model. Additionally, as the database grows you only pay for the storage on a consistent basis and then the read/writes as they happen (the typical billing for serverless NoSQL databases).

Fast

While I didn't do any tests to see the actual wake times (and how quickly the database slept), I didn't notice anything different from other serverless offerings. Within a few milliseconds, the database was up and response and then stayed awake for the remainder of a typical session. Additionally, the reads and writes didn't seem to be any faster or slower than a typical static Postgres instance which is fantastic as I hope for it to be a replacement in the future.

The drawbacks

As for the drawbacks, there honestly weren't many. I'd group all of them into the fact that it's a newer company / technology so the integrations and ease of use isn't as refined as a more mature company.

Connecting to a Cloud Run instance

While connecting to a Cloud Run instance is seamless when using Cloud SQL (obviously because it's in the Google Cloud Platform suite), it's a little bit more of a setup for CockroachDB. First, you need to store your certificates within your repository which isn't the worst but I wouldn't say it's ideal for security. This just means that access to that repository may need a little bit more thought.

Testing & database migrations

As for automated database migrations, it was a little more hacky to configure. The SQLAlchemy Utils library I use supports Postgres but not CockroachDB (at the moment) so using it for working with test databases and running database migrations didn't work seamlessly. It wasn't a huge issue as it was simple to extend the library to work with CockroachDB.

How you can use it!

And for the fun part, how you can use it! It's as simple to going to their Get started page and select CockroachDB Serverless. From there you'll just need to create an account (no credit-card required), select some info about your database, and you're all set! Their dashboard gives all the information you'll need to connect to it just like any other SQL database!

Summary

Thanks for reading as always! Feel free to drop a comment with your experience or any questions! If you want to learn more about building modern backend applications check out my previous articles,

Prompt Engineer