does using physical replication between postgres instances exhibit the same problems as logical replication? if so, why? this is a part of the "we should be using cockroachdb" conversation at my company.

there are two problems associated with replication: - replica lag due to asynchronous replication: revisions not being available in a replica by the request hits. This would affect both physical and logical replication. - internal MVCC transaction ids changing: I believe this is specific exclusively to logical replication

and the problem with the former is potentially requesting a revision that the replica doesn't know about yet and getting an error from SpiceDB? it's good to know that physical replication does address the mvcc concern

Yeah, I think I touched about this a few weeks back in a different thread. @williamdclt has experience on physically replicated postgres with SpiceDB, and what they've been doing is to issue a request to the replicas, and if a specific "revision does not exist" error is returned, then they retry against the SpiceDB cluster that is talking to the primary. Also I think it wouldn't be too hard to implement this natively into SpiceDB with some sort of

datastore

wrapper