5 ms·

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 Mon

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 2y ago
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 2y ago
  Look forward to reading it
  - bcantrill 2y ago
    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 https://rfd.shared.oxide.computer/rfd/0508 [1] https://rfd.shared.oxide.computer/rfd/0053 https://rfd.shared.oxide.computer/rfd/0053 [2] https://rfd.shared.oxide.computer/rfd/0110 https://rfd.shared.oxide.computer/rfd/0110
    - redwood 2y ago
      Thanks: I think there's a category you're missing, which is transactional document oriented databases with strongly consistent secondary indexes.
    - moderation 2y ago
      Not Jepsen tested but rqlite [0] could be in the running and meet the requirements and is open source (MIT). 0. https://rqlite.io/ https://rqlite.io/
    - Rawennum 2y ago
      Hi, Does multi-region replication also go under the apache license?
PeterCorless 2y ago
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 2y ago
  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 2y ago
    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 https://rfd.shared.oxide.computer/rfd/0053#rfd48
    - redwood 2y ago
      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 https://db-engines.com/en/ranking

bcantrill 2y ago

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 2y ago
Look forward to reading it
- bcantrill 2y ago
  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 https://rfd.shared.oxide.computer/rfd/0508 [1] https://rfd.shared.oxide.computer/rfd/0053 https://rfd.shared.oxide.computer/rfd/0053 [2] https://rfd.shared.oxide.computer/rfd/0110 https://rfd.shared.oxide.computer/rfd/0110
  - redwood 2y ago
    Thanks: I think there's a category you're missing, which is transactional document oriented databases with strongly consistent secondary indexes.
  - moderation 2y ago
    Not Jepsen tested but rqlite [0] could be in the running and meet the requirements and is open source (MIT). 0. https://rqlite.io/ https://rqlite.io/
  - Rawennum 2y ago
    Hi, Does multi-region replication also go under the apache license?

PeterCorless 2y ago

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 2y ago
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 2y ago
  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 https://rfd.shared.oxide.computer/rfd/0053#rfd48
  - redwood 2y ago
    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 https://db-engines.com/en/ranking