Reads do not share a snapshot
An ordinary multi-shard read does not establish one shared Postgres snapshot across its destinations. Concurrent writes can therefore cause different shards to reflect different points in time within the same result.Multi-shard writes are not atomic
Neki commits each shard separately. It does not use two-phase commit to make every shard succeed or fail together. If one shard fails after another commits, the statement can leave different outcomes on the participating shards.Enforce a one-shard transaction
The default transaction routing mode ismulti, which permits a transaction to
reach more than one shard without making its commit atomic. Set the mode to
single before starting a transaction when the application wants Neki to
prevent that transaction from expanding to another shard:
Distributed and atomic cross-shard transactions are not yet supported. Keep a
transaction on one shard when its writes must commit or roll back together.