Comment by adevx | Hacker News Reader

Comment by adevx | Hacker News Reader

Parent Full thread

I've tried CockroachDB as well as YugabyteDB. A distributed ACID transaction Database sounds like the holy grail, but it comes with a price. For CockroachDB the performance penalty was high, even though I'm sure I could have squeezed out more performance if I was to design my DDL specifically for CRDB.

There was an inconsistency issue when deleting a ton of (self referencing foreign key) rows in rapid succession. The results of a "select count(*) from table" returned different results than a "select count(id) from table". After some delay the results came back in sync again.

As I was trying to shoehorn an existing PostgreSQL database into CRDB, I had to find solutions for SELECT .. FOR UPDATE, finding alternatives for triggers, issues with the query builder I use (knex.js). In the end it was too much, not even considering lack of backups and the risk of a VC funded company going belly up. I do hope they gain a solid foothold and these NewSQL databases gain more traction.

We take our claims if correctness very seriously. The behavior you're describing, depending on exactly what you're doing, is likely an allowed serializable history, which is the isolation level we claim to support. See [0] for a deeper dive on the subject. Either way, you should show us what you found (if you haven't already).

As for your performance analysis, do share your results and methodology. We published an in-depth, reproducible comparison with YugaByte here [1] in addition to publishing our TPCC-100k numbers[2]. If you're seeing performance that doesn't line up with the above, let us know.

[0]: https://www.cockroachlabs.com/blog/consistency-model/

[1]: https://www.cockroachlabs.com/blog/unpacking-competitive-ben...

[2]: https://www.cockroachlabs.com/blog/tpcc-100k/

Thanks, "serializable history" could well have been the root cause. I did discuss this in the forum but was unable to resolve it at that time.

After your opening sentence I kept waiting for the comparison to Yugabyte but you never mentioned it again. How did it go?

My testing of YugabyteDB was not as extensive as CockroachDB. I had issues importing my PostgreSQL schema + data (I did use ysql_dump) I got timeouts and an occasional 100% cpu crash. I was able to import after trimming the amount of data and dumbing down the schema (dropping foreign key references) CPU usage was much higher than PostgreSQL and I found the overall tooling and setup less polished compared to CockroachDB.

Reply on news.ycombinator.com