Try looking at cockroachDB, the only thing holding me back on that is the absence of triggers.

It was a brain fart: Meant to say CockroachDB instead of CouchBase. Oops.

So yeah, it's on my short list. :) I've used triggers in one project recently, but that was literally the first time in five years so it's not as much of a must-have for me.

I guess its depends, for many use cases, it can be managed at application level. I've parted ways with FK for a long time since it created more hassles than it solved esp when it comes to sharding and replications.

You can always handle it at the application level.

The trick is that it's better to have the extra guard rails. And all of Couchbase, Yugabase, and Citus support foreign keys even with sharding and replication, so that's not an issue when the DB supports it.

I said Couchbase above but meant CockroachDB. Brain fart, but can't edit the message now. :|

that's very common in distributed databases. even traditional databases, it's very common to not have FKs on large tables, and just handle it in software. indexing billions or more of rows is non-trivial.

Foreign keys come at a cost, especially in distributed database. It's just a fact. If you can avoid them, it's great.

didn't notice that. Wow that's pretty basic...