Tailscale mention they want to run tests locally, not deal with MySQL/Postgres ops overhead themselves, and also avoid vendor lock-in (rules out RDS / Aurora, PlanetScale, CockroachDB, YugaByte, Spanner et al).

May be Oracle remains an option. ;)

Maybe I'm doing something wrong, but our team has like a few dozens of PostgreSQL RDS running on AWS for the past four years and the ops is... Basically zero?

I don't see how CockroachDB ends up in your list of DBs that lead to vendor lock-in or being unable to run a cluster locally, because it's open source and you can run your own cluster. Is there something about it I haven't spotted that puts it in that list?

CockroachDB is licensed under BSL, so it is not really open source rather a source open or source available project. I checked their LICENSE file [0] and it mentions bunch of other open source licenses with BSL. I randomly checked a code file [1] and it seems the code is licensed under BSL.

[0] - https://github.com/cockroachdb/cockroach/blob/2c4e2c6/LICENS...

[1] - https://github.com/cockroachdb/cockroach/blob/2c4e2c6/pkg/kv...

Very interesting. I'd never heard of it but apparently MariaDB uses it too.

TL;DR is the source is available but you can't use it in production without paying a fee. However versions older than 4 years become truly open source, so you can use old versions for free.

Interesting compromise. Might be better than "open core".

That’s not quite right. You can very much use the bsl code in production without a license and many, many companies do. The BSL contains a space for additional use grants. In crdb’s license, you can use the product for anything except building a hosted database as a service product. The definition of what that is is a little bit vague but it more or less means that the users of the product you sell shouldn’t be able to cause schema changes. This is all just protection against cloud providers taking the product and reselling it. I believe also the terms of this bsl are that it becomes Apache 3 years after the code has been released.

You absolutely cannot use the BSL code in production without a commercial license. That's literally the first thing it says:

> The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work. The Licensor may make an Additional Use Grant, above, permitting limited production use.

Maybe specific software modifies that as you say, but the base BSL doesn't. I agree it's super vaguely worded ("production" isn't defined at all). Also it turns out MariaDB itself isn't BSL licensed - it's GPL, just some extra projects around it.

> The Licensor may make an Additional Use Grant, above, permitting limited production use.

See the text of the Additional Use Grant for CockroachDB [1]:

> Additional Use Grant: You may make use of the Licensed Work, provided that you may not use the Licensed Work for a Database Service.

> A “Database Service” is a commercial offering that allows third parties (other than your employees an contractors) to access the functionality of the Licensed Work by creating tables whose schemas are controlled by such third parties.

(disclaimer: I work at Cockroach Labs)

[1] - https://github.com/cockroachdb/cockroach/blob/master/license...

Ops overhead would be my guess.

Take a look at https://litestream.io/guides/systemd/ and compare that with CockroachDB's.

In all fairness, litestream is no CockroachDB/PlanetScale/YugaByte; but why pay the ops overhead (and your lawyers to make sense of their "OSS" licenses) when litestream would do just as nicely.

TFA goes (emphasis mine):

Litestream..grabs a lock so that no other process can checkpoint. It then watches the WAL file and streams the appended blocks up to S3, periodically checkpointing the database for you when it has the necessary segments uploaded. ___This gives you near real time backups and lets you replay your database from S3 trivially..It's a great hack, and a small enough program that I could read my way through it entirely before committing to it.___

they've already had to migrate twice due to questionable technology decisions. having to migrate again due to needing to change cloud providers seems a lot less likely than having to migrate again because their outside the box technology choice didn't pan out.

Pretty sure you could track down instances of this technology going back decades now. Nothing is new under the sun. Doesn't mean you can use it.

I don't think they are claiming to have invented database replication, so what?