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?
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.
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."
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
