Hacker News Reader

Comment by redwood | Hacker News Reader

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?

View on HN

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.

Look forward to reading it

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

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

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

0. https://rqlite.io/

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

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.

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

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

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

Reply on news.ycombinator.com