3 ms·

The top concern I've gotten from dev teams when proposing HA distributed postgres (e.g through RDS Aurora global) is that eventual consistency is not suitable f

The top concern I've gotten from dev teams when proposing HA distributed postgres (e.g through RDS Aurora global) is that eventual consistency is not suitable for many workloads. Does Neki solve for this, and if so how? My understanding of CAP theorem is that this basically requires some compromises around availability, but I'm curious as to what that looks like in practice here.

mcpherrinm 24d ago
Assuming it works the same way as their MySQL product, Vitess: The usual way to run it is that you partition your db based on something like a user, so that single user gets a consistent DB, but anything cross-shard may not be. I know when I worked at Block, Cashapp was using Vitess and getting cross-shard DB writes down and functioning correctly was one of the major blockers to adoption. (though I just did tls management for vitess and didn't write any workloads on top of it, so my impression might be a bit off)
- ronfriedhaber 24d ago
  Therefore, Consistency guarantees are based on implementing application-specific partitioning (correctly)?
  - mcpherrinm 24d ago
    Yeah. Vitess does have some options for atomic cross-shard commits using an additional database to track two-phase commits, but that's expensive so you probably want to avoid that. https://vitess.io/docs/25.0/reference/features/distributed-transaction/ https://vitess.io/docs/25.0/reference/features/distributed-t...
  - osalberger 23d ago
    The consistency guarentee assuming repeatable read or higher on each shard is parallel snapshot isolation, which is technically still higher than postgres read committed. If you have serializable on each shard and you chop transactions so you have no cross shard transactions, the application is technically still serializable, it just behaves like two independent deployments of the application for different shards
harshitgangal 24d ago
[dead]
arrowleaf 24d ago
Same here, first thing I need to know when considering a distributed system is how consistency is handled. If it's eventual consistency, what is the replication lag like? If it's strong consistency, can their network handle that? What happens when a node goes down?

mcpherrinm 24d ago

Assuming it works the same way as their MySQL product, Vitess: The usual way to run it is that you partition your db based on something like a user, so that single user gets a consistent DB, but anything cross-shard may not be. I know when I worked at Block, Cashapp was using Vitess and getting cross-shard DB writes down and functioning correctly was one of the major blockers to adoption. (though I just did tls management for vitess and didn't write any workloads on top of it, so my impression might be a bit off)

ronfriedhaber 24d ago
Therefore, Consistency guarantees are based on implementing application-specific partitioning (correctly)?
- mcpherrinm 24d ago
  Yeah. Vitess does have some options for atomic cross-shard commits using an additional database to track two-phase commits, but that's expensive so you probably want to avoid that. https://vitess.io/docs/25.0/reference/features/distributed-transaction/ https://vitess.io/docs/25.0/reference/features/distributed-t...
- osalberger 23d ago
  The consistency guarentee assuming repeatable read or higher on each shard is parallel snapshot isolation, which is technically still higher than postgres read committed. If you have serializable on each shard and you chop transactions so you have no cross shard transactions, the application is technically still serializable, it just behaves like two independent deployments of the application for different shards

harshitgangal 24d ago

[dead]

arrowleaf 24d ago

Same here, first thing I need to know when considering a distributed system is how consistency is handled. If it's eventual consistency, what is the replication lag like? If it's strong consistency, can their network handle that? What happens when a node goes down?