Therefore I tried to calculate some kind of pricing comparison, I'm looking at the cpu alone now

Can confirm the inability to select null values. Have not yet found a reasonable pattern / workaround.. The reasoning seems to be that null values are not stored-- it's displayed as null in csql, but in reality, that data just does not exist. For the record, CockroachDB does not store null either, but it allows querying null. A workaround may be stepping through the full table manually using the PK (which can never be null) checking for null "in app" and cleaning them that way. Noticed INSERTS are treated as UPSERT unless you use IF NOT EXISTS... ScyllaDB doesn't give a f__k if it's overwriting an existing row, lol. I can live with the UPSERT footgun, though. Agreed the null footgun is far more annoying.

Found a solution to address the lack of WHERE x = NULL SELECT * FROM users; Then you can plug your PK into. UPDATE users SET address='' WHERE user_id IN (9affeac3-5d92-111d-779c-55eb6d78a806, ...) IF address=null; Then you can do your SELECT to do your repair. SELECT * FROM users WHERE address=''; _______________________ Another footgun: No default values for columns in CREATE TABLE. Very annoying. Another footgun: Only "=" and "IN (...)" is supported in WHERE for partition keys. https://docs.scylladb.com/stable/cql/dml.html#the-where-clau... This means, you cannot do UPDATE WHERE user_id > 0 .... I'm starting to really appreciate the effort CockroachDB went to, to make their version of "CQL" postgres compatible, even though architecturally they are both key-value store databases under the hood... it's just a shame CockroachDB just has far lower performance because of enforced consisten…