I think I’ve done something like this with two tables with a row per shard and an exclusive (FOR NO KEY UPDATE) lock there for writers, but it wasn’t performance critical. I found that the page-based serializable checks had way too many false positives compared to row-based locking. The CAS query here with just one relation and statement is clever and I assume has much better peak throughput!
score 1 · canonical
I strongly agree with this.
There should be a lower level functional language describing relations (tables & indices) and operations on them.
I mean, every database has this inside (the query plan - explain), I just want a syntax defined and an API to run queries with it. (For the write path, it might be a bit more complex, but the read operations are straightforward).
Of course SQL is fine as a higher level language. It’s even possible that during development you might record the optimised query plan along with the SQL, and have checks that they match so that you are notified (and can accept/reject) any change (due to existence of an extra index, for example).
score 1 · canonical
Applying the vibecoding tag here is only going to create a “bubble”, and seems like a terrible idea for building a cohesive community.
score 1 · canonical