and those internal transaction IDs won't line up between instances

I know that @williamdclt is running with Postgres replicas, so based on his experience, I'd be surprised transaction IDs are not the same between primary and replicas. The challenge is replication delay caused by asynchronous replication - if you ask a replica for a transaction ID that hasn't been replicated yet, it will fail. In that regard I also know that William addressed this by checking the error returned, and if it's specifically "revision not found" then they retry the request on a SpiceDB cluster that is connected to the postgres primary. We can probably do something similar natively, we just haven't done it yet. I also wonder if doing synchronous replication may be a reasonable alternative for read intensive workloads. Increasing write latency may be acceptable to some folks.

Yes this could work for us

ah yeah it also depends on what kind of replication you're doing. if it's logical replication you'll run into issues for sure - that's the problem we've been having.

TIL logical replication, didn't know it was a thing - that'd make sense in that case