Distributed Bytes

RocksDB development finds a CPU bug rocksdb.org/blog/2026/02/1…

Three Lenses on Coordination jhellerstein.github.io/blog/three-spe…

Consensus Board Game matklad.github.io/2026/03/19/con…

@DistribSystems Thanks for sharing this! Happy to answer any questions

the mathematics of compression in database systems bitsxpages.com/p/the-mathemat… I started thinking about compression when implementing prefix compression for SlateDB. When I ran benchmarks, I noticed that performance seemed "worse" despite improved compression ratios.

I think this is broadly correct. But I'd focus on specification instead - getting good at thinking about and formally writing down the safety, liveness, and performance properties of the system. Verification follows from specification.

Formal Methods Beyond Correctness: Isolation & Permissiveness of Distributed Transactions in MongoDB mongodb.com/company/blog/e…

One-off Verified Transpilation with Claude will62794.github.io/verification/l… We can automatically check correctness properties of a TLA+ specification using TLC, a model checker that will exhaustively explore a spec’s reachable states and check that some specified property holds.

One thing I find interesting about OpenAI's Postgres blog post is how similar their approach is to the one we took in the early days of EC2. Keeping up with rapid early scale is a whole set of technical challenges, and you have to pick your battles.

Scaling PostgreSQL to power 800 million ChatGPT users openai.com/index/scaling-…

Aurora DSQL offers strongly consistent reads across multiple AWS regions, faster than the speed of light. How is this possible?

SpiceDB is an open-source, Google Zanzibar -inspired database system for real-time, security-critical application permissions. authzed.com/docs/spicedb/g…

On Idempotency Keys morling.dev/blog/on-idempo… In distributed systems, there’s a common understanding that it is not possible to guarantee exactly-once delivery of messages. What is possible though is exactly-once processing.

TLA+ Community Event 2026 - conf.tlapl.us/2026-etaps/ Co-located with ETAPS 2026 in Torino, Italy, on April 12, 2026. Submit talk proposals by Jan 31 on: - industrial or academic case studies, - new tools for TLA+ or add-ons to existing tools, - innovative use of existing tools or reports on their shortcomings, - use of TLA+ in education.

Do you like databases? Do you want to hear two database professors rant about them? Do you need one of those professors to have a Turing Award for databases? If yes, then join Mike Stonebraker and I next Wed Dec 10 @ 1:00pm EST for database hot takes: dbos.dev/webcast-2025-i…

What Does Write Skew Look Like? justinjaffray.com/what-does-writ… This post is about gaining intuition for Write Skew, and, by extension, Snapshot Isolation. Snapshot Isolation is billed as a transaction isolation level that offers a good mix between performance and correctness.

Distributed Locking with Redis Redlock When multiple services need mutually exclusive access to a shared resource (files, counters, payments, job execution), you need a distributed lock. I recently came across this redlock algorithm by redis and it's a true distributed systems masterpiece BUT DONT USE IT FOR CONSENSUS --- A single-node Redis lock (SET key value NX PX=TTL) is fast but unsafe: Redis can crash → lock disappears Network partitions → split-brain Clients can pause → act with expired locks So Redis proposed Redlock: Use N = 5 independent Redis nodes. Client tries to acquire the lock on all nodes with a TTL. If it obtains ≥ 3/5 locks within a bounded time window → lock is considered acquired. But here’s the problem — Redlock relies on timing assumptions. To be safe, Redlock implicitly assumes: bounded clock drift bounded process pauses bounded network delays TTLs expiring “on time” In real distributed systems, none of these hold. Your process can GC-pause for seconds. Packets can be delayed for minutes (yes, this has happened at GitHub). NTP can jump the system clock forward/backwards. A Redis node can crash and lose the key before syncing. If any of these happen, Redlock can violate safety: Two clients can both think they hold the lock. This is fatal if the lock protects correctness (e.g., money movement, inventory writes). The deeper issue: Redlock has no fencing tokens. Correct distributed locking requires monotonically increasing fencing tokens: Client A acquires lock → token 33 Client B acquires lock → token 34 Downstream systems (DB, S3, job processor) must reject old tokens. Redlock returns random values — not monotonic. So you can't build correctness guarantees on top of it. TL;DR Redlock ≠ consensus Redlock ≠ safe under arbitrary delays Redlock ≠ safe under clock drift Redlock ≠ safe for correctness-critical locks Redlock is okay only for “prevent duplicate work” use cases If correctness matters → use ZooKeeper/etcd/Consul. They implement real consensus and generate fencing tokens reliably.

How to do distributed locking martin.kleppmann.com/2016/02/08/how… Redis has been making inroads into areas of data management where there are stronger consistency and durability expectations. Distributed locking is one of those areas. Let’s examine it in some more detail.

[new blog post] Disaggregated Database Management Systems muratbuffalo.blogspot.com/2025/11/disagg…

I have no doubt that disaggregation is going to continue to be a good bet in the DB market. The really interesting thing to watch is how the hardware trends of AI (especially tons of network bandwidth, and highly connected low-latency networks) change disaggregated architectures.