Versions and last-writer-wins

Every record carries a monotonic version. suo uses it, not arrival order, to decide which write sticks.

Setting version

Pass your own version — typically your record's updatedAt timestamp or a database revision number — on upsert and delete. If you omit it, the server assigns one from the time it accepts the write.

{ "action": "upsert", "record": { "objectID": "a", "title": "…", "version": 1732550400000 } }

Last-writer-wins

If two writes to the same objectID arrive out of order — a retry, a slow network, a queued batch replaying after a fresher direct write — the one with the higher version wins. A write with a lower or equal version than what is already stored is accepted but ignored, and counted in the response as ignoredAsStale:

{ "dataVersion": 481, "applied": 3, "ignoredAsStale": 1 }

This is why version should track your own source of truth's update time, not the time you happen to call the API.

Deletes are tombstones

A delete does not immediately erase a record; it becomes a versioned tombstone kept for 30 days, so a delayed upsert from before the delete cannot bring the record back. After 30 days the tombstone itself is dropped.

Read-your-writes

Every successful write returns the index's new dataVersion. Pass it as minDataVersion on a search against the same index's primary, and the primary will not answer until it has applied at least that version — so a search right after a write is guaranteed to see it, without a fixed delay or a retry loop.

{ "q": "note-taking", "minDataVersion": 481 }

This only applies to the primary. Reads against a replica (used for hot, read-heavy indexes) are eventually consistent — see Partitions for when an index gets replicas versus a partition per key.