DEVOURED
Protocols for transactional usage of object storage
Almog Gavra details how to achieve serializable online transactional processing (OLTP) on object storage by using specific atomic and conditional read/write primitives, despite the high cost of LIST operations.
What: Almog Gavra, on May 18, 2026, explains protocols for building correct transactional applications on object storage, using primitives like atomic PUTs, conditional PUT If-Match/If-None-Match, and strongly consistent LISTs, along with atomic and conditional GETs. The article highlights that while GETs are cheap, LIST operations on S3 can cost nearly 12x more. This approach is motivated by SlateDB's transactional write module.
Why it matters: This article demonstrates how fundamental guarantees like serializability, traditionally associated with relational databases, can be engineered on highly distributed, eventually consistent object storage systems by carefully leveraging specific low-level primitives, pushing the boundaries of what these systems can reliably support for transactional workloads.
Takeaway: If designing a data system on object storage requiring transactional guarantees, carefully evaluate the use of conditional writes and consistent listings, being mindful of the cost implications, especially for LIST operations on services like S3.
Deep dive
- The article focuses on design patterns for using object storage (like S3) correctly for Online Transactional Processing (OLTP) use cases, aiming for serializable history.
- It identifies three key write primitives: unconditional atomic PUTs, and conditional PUT If-None-Match / If-Match for compare-and-set operations.
- Three read primitives are also crucial: atomic GETs, conditional GET If-None-Match (for cached data), and strongly consistent LIST requests.
- A key performance consideration is that LIST operations on S3 are significantly more expensive than GETs (nearly 12x more).
- The "baseline protocol" uses direct atomic PUTs, providing correctness but suffering from high latency.
- The "simple conditional protocol" improves latency by batching writes into a single file and using PUT If-Match to resolve conflicts, but leads to 3-round-trip costs on contention. OpenData Buffer uses this.
- The "sequenced write protocol" uses file names as guards, incrementing them with each write, reducing contention cost to two round-trips but requiring garbage collection.
- For single-writer systems (like SlateDB), conflicts can lead to writer failure, often using "epochs" encoded in files to distinguish roles (main writer, garbage collector, compactor).
- Safe garbage collection requires "boundary files" to prevent old writers from inadvertently creating data branches after cleanup.
- The author mentions that SlateDB's protocols are formally verified using the Fizzbee specification language.
- The core tradeoff is safety versus contention cost, emphasizing the need for robust protocols to ensure consistency during failures.
Decoder
- Object storage: A data storage architecture for handling large amounts of unstructured data, where data is managed as objects rather than files in a hierarchy (e.g., AWS S3, Google Cloud Storage).
- Online Transactional Processing (OLTP): A type of data processing that facilitates and manages transaction-oriented applications, typically involving frequent, short, atomic transactions (e.g., bank transactions, e-commerce orders).
- Serializable history: A strong isolation level in database transactions ensuring that the concurrent execution of multiple transactions produces the same result as if they were executed sequentially, preventing data inconsistencies.
- PUT If-None-Match / If-Match: Conditional write operations in object storage.
If-None-Matchsucceeds only if the object does not exist;If-Matchsucceeds only if the object's ETag (content hash/version) matches a specified value. These are used for compare-and-set semantics. - Consistent LIST: A LIST operation on object storage that guarantees to return all objects that have been successfully written and acknowledged, reflecting the latest state.
- Atomic PUT / GET: Write or read operations that guarantee either the entire operation completes successfully, or it fails entirely, without any partial or corrupted state.
Original article
Full article content is not available for inline reading.
Explore all 58 articles in today's digest
Fresh dev news, AI-digested daily. Never miss a trend at devoured.fyi