The Fly promise

Chris McCord has been posting about CockroachDB recently. This goes hand in hand with some of the points I made in my closing keynote at GigCity Elixir (video coming soon-ish). I didn't talk about Cockroach specifically because that was tangential but this reinforces my understanding of Fly and their view of a modern stack.

They want a properly geo-distributed database. Where the DB is close to the app and close to the user. They have distribution of app servers already. With Tigris they got distributed file storage (and a distributed key value store, actually). But distributed SQL is significantly tougher.

I think this vision is compelling and I want to see it at its best. I think Electric SQL is closer to a solution I'd enjoy than CockroachDB though.

I went digging into CockroachDB about 3 or so years ago because they seemed to be the solution to my beef with databases. The story seems largely the same or slightly worse today. It is probably fine for many cases. I have concerns. I'll try to give a balanced view.

CockroachDB tackles a really hard problem and seems to do it well. Distributed geo-replicated relational databases with a good consistency-story and papering over a lot of the rough edges that the CAP theorem hits us with. Much like what Google Spanner does for MySQL compatible, CockroachDB does for Postgres-compatible.

I have one technical frustration that I think is unavoidable for tackling this problem. It seems kind of heavy. At least reading their recommendations for hardware, CockroachDB is not lightweight. It is built for large global scale and the minimum size is likely not very interesting to them. Maybe it can actually run on a single core in very little memory but I don't get that impression and haven't find any indication of that. This is probably a fine trade-off but it is a concern of mine. In the end it might not matter due to the more important concerns.

The rest is business, licensing and ideology. I'm an open source idealist with a bit of a pragmatic streak. I get why they licensed BSL in 2019 and as long as they do the Apache license for anything that's been out for X years I don't find it terribly offensive. But I don't enjoy it and wouldn't necessarily invest myself in their community. And the picture is more complex. As an open core offering they also have the CCL since 2017 which covers the parts of CockroachDB that are not open source but are source available, whether free or paid.

So let's consider what is in that set. Backups. Changefeeds. Multi-region.

I think it is hard to consider CockroachDB complete without the CCL parts and as such the part that will be open source is actually fairly barebones. And that probably means that what you could run yourself on Fly is barebones. So if you want what Cockroach offers you should pay and use the whole thing.

Now Fly is not open source. AWS RDS is not open source. It might be worth paying for a really powerful database. And pay you will. The "serverless" tier of CockroachDB is single-region so it shouldn't be in this conversation. The next tier starts at $300/month.

I was very excited about the premise of CockroachDB to solve the frustrations of databases without forcing me out of Postgres-land at one time. I can't quite get excited about it currently. If Fly partners with Cockroach Labs to offer a more approachable commercial version of the current offering, that could be quite compelling. Right now I only see it making sense for apps that know they will be dealing with large things from day one.

Have I misunderstood the CockroachDB offering? Are you keen on it? Are you angry about them? You can reach me on the Fediverse where I'm @lawik@fosstodon.org or by responding to this email to lars@underjord.io.

Thanks for reading. I appreciate it.