[bcantrill]

Yes, we are -- and it's worked well for us! (The most acute issue we hit was actually a gnarly OS issue[0][1].) That said, we are not currently a Cockroach Labs customer and we will not be becoming one for purposes of licensing CockroachDB. We are abiding by the terms of the BSL, and the version that we are on (22.1) will be Apache licensed in May 2025; by that point, we will maintain our own Apache-licensed fork for purposes of being the database for the control plane included in the Oxide rack.

We will be outlining our current direction in an RFD[2] that we will make public -- and we will also make public our RFDs that pertain to our selection of CockroachDB and the other alternatives that we evaluated; stay tuned!

[0] https://www.illumos.org/issues/15254

[1] https://oxide-and-friends.transistor.fm/episodes/a-debugging...

[2] https://rfd.shared.oxide.computer/rfd/0001

[Spivak]

And like clockwork too.

1. Company builds cool OSS and releases it to the world.

2. The product becomes stable, mature, and users are happy with its feature set. Development slows down.

3. Company starts having to make money so they relicense future code.

4. A few large users of the software (that company was hoping for $$$ from) realize that since it's mature and stable it's massively lower cost to just maintain the last OSS version.

5. At the time of the license chance the new OSS fork is identical to what everyone is already using and so it's the the least resistance migration.

6. The consortium of actual users of the software drive its future direction instead of the company.

I'm not mad about the cycle, it's the moment VC backed software gets turned over to the community. But I always wonder how it turns out for the companies in the long run.

[maxloh]

Any real world example for this?

[mcint]

Search keyword is "relicense", and especially "BSL" or "Cloud license".

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Redis, rhymes with this. Redis Labs, which captures the smallest sliver of the value OSS Redis provides, is valued at $2 B, with 2023 revenue of $151 M.

MongoDB, aka AWS "DocumentDB" (Microsoft/Azure Cosmos DB seems to have a different lineage). Mongo had $458 M in revenue Q4 2023 [1].

[1]: https://www.businessinsider.com/redis-labs-ceo-ipo-2-billion...

[2]: https://investors.mongodb.com/news-releases/news-release-det...

[mushi]

> aka AWS “DocumentDB”

Nope, just the same API, completely unrelated codebase.

[redwood]

Outside Olobserver here... isn't it a huge distraction from your core mission to be maintaining a fork of a database engine? Why not just use something like MongoDB Community if you're trying to avoid paying for database and need a horizontally scalable distributed transactional system?

[bcantrill]

No -- but I will leave it to the RFD that I'm currently writing (and to the others that we will make public) to explain the rationale.

[redwood]

Look forward to reading it

[bcantrill]

As promised, I have made RFD 508 ("Whither CockroachDB?")[0] public -- along with RFD 53[1] and RFD 110[2], which explain the problem we are trying to solve and our rationale for CockroachDB, respectively.

[0] https://rfd.shared.oxide.computer/rfd/0508

[1] https://rfd.shared.oxide.computer/rfd/0053

[2] https://rfd.shared.oxide.computer/rfd/0110

[moderation]

Not Jepsen tested but rqlite [0] could be in the running and meet the requirements and is open source (MIT).

0. https://rqlite.io/

[redwood]

Thanks: I think there's a category you're missing, which is transactional document oriented databases with strongly consistent secondary indexes.

[Rawennum]

Hi, Does multi-region replication also go under the apache license?

[PeterCorless]

MongoDB is not a drop-in replacement for a CockroachDB.

It's not SQL.

While MongoDB has come a long way in terms of ACID compliance, etc., you still would need to map everything you've done to MongoDB.

That's more work than forking code you're familiar with that already is working.

[redwood]

That makes sense it's more that from first principles when exploring the options it looked like and I see below based on the public page, it wasn't even contemplated.. instead various key value stores without transactionality, and with eventual consistency and limited secondary indexing capabilities were looked at that are not widely used.

I guess my deeper point is there's sort of the illusion of a comprehensive analysis in the post when actually engines that haven't been widely used in 5-10 years were analyzed when more widely deployed engines weren't even analyzd that's what was odd

[PeterCorless]

RFD 53 addressed why they avoided NoSQL in general:

"NoSQL systems (e.g., Cassandra, Riak). The challenges of building relational, transactional applications atop these systems is well known. These systems also generally predate the modern emphasis on hands-off operation, which is critical for supporting a system that we will not be operating directly."

https://rfd.shared.oxide.computer/rfd/0053#rfd48

[redwood]

My point is to conflate the entire non-relational category into this bucket when one of the two items referenced peaked >10 years ago and the other isn't generally strongly consistent at write time, transactional, or with strongly consistent secondary indexes, is a limited and misleading POV https://db-engines.com/en/ranking

[franckpachot]

YugabyteDB is and will always be Apache2. It is PostgreSQL compatible (the query layer is a fork of PostgreSQL) so the migration from CockroachDB, which implements a subset of PostgreSQL features, is easy.