One Round Trip, Every Command Twice

Classic leader-based protocols such as Raft, Paxos and Zab need two round trips to commit a command: one from the client to the leader, and one from the leader to its followers. Fast-path protocols like Fast Paxos, EPaxos and SwiftPaxos get this down to one round trip, but the fast path is built into the protocol's design. Production teams can't easily drop a tested consensus engine for one of these. Jetpack (OSDI '26), reviewed by Murat Demirbas and Aleksey Charapko, is a shim layer that adds a 1-RTT fast path to an existing protocol with minimal changes.

How it works

The client sends each command to two paths at once: the fast path and the original consensus path. The fast path checks for key conflicts. If there are none and a supermajority (about 3/4 of nodes) promises to accept the command, it commits in one round trip. To keep everyone in agreement, proposers on the original path promise not to order conflicting commands ahead of fast-committed ones.

Portability has a cost. The original engine doesn't know the fast path exists, so it runs its full replication cycle anyway. There are two logs, every command crosses the network twice, and replicas process each command twice.

Commitment and execution also come apart. A fast commit only confirms durability. The state machine still runs in the order of the slow-path log. That's fine for fire-and-forget PUTs. But if a client issues PUT(key) and then GET(key), the shim sees the unexecuted PUT in its conflict pool and sends the GET down the 2-RTT path. Results stay linearizable, but the read pays full latency. Demirbas ties this to (SOSP '21): a write can be acknowledged before it executes because it returns no state to the client, but a read can't.

TigerBeetle's post takes a classic contention workload and shows how to run it fast. Every transaction updates a customer, a teller and a branch balance, then appends a history row. Because there are only a few tellers and branches, transactions keep colliding on the same rows. The post claims three techniques together give a "100x" improvement. Its own benchmark shows about 65x.

Step 1: Model it as linked transfers

The SQL version issues three row updates and one insert inside a transaction. TigerBeetle expresses the same deposit as two double-entry transfers: bank aggregate account → branch, and teller → customer. A Linked flag chains them so both commit or neither does. The history table goes away because TigerBeetle is immutable and keeps transfer history automatically. A bank-wide aggregate account replaces a scan-and-sum query. In a row-locking database that design would serialize every transaction. TigerBeetle says it is built for this kind of high-contention access.

Step 2: Batch instead of adding connections

Copying the connection-pool pattern, with one transaction per request across many goroutines and several client instances, gave no throughput gain at all. TigerBeetle's concurrency comes from batches instead. A single request can carry up to 8,189 operations, which spreads the fixed network, replication and processing costs across all of them. With one client and large batches, the benchmark reached 454,518 transactions/s (909,162 transfers/s).

Applications don't have to build batches themselves. Each client allows only one outstanding request. While that request is in flight, the client collects new operations into the next batch. This adds no artificial delay. In Go, many goroutines share one thread-safe client. The authors say most users need only one client for throughput, and they recommend four physically separate "gateway" clients so the system survives a client failure.

Neki is PlanetScale's sharding layer for unmodified PostgreSQL. It is not a fork and not a wire-compatible reimplementation. Harshit Gangal's post goes through the architecture from the bottom up. It describes design and has no benchmarks.

Per-instance plumbing

Each Postgres instance runs with two companion processes. PostgresManager is PID 1 in the container. It starts and stops Postgres, owns the data directory, and configures replication. The Sidecar pools connections and tells the rest of the cluster whether its instance is healthy and whether it is a primary or a replica. The pool has three checkout modes, chosen from a hint the Router sends: autocommit statements return the connection as soon as they finish, multi-statement transactions hold it until commit or rollback, and session-scoped advisory locks get a dedicated backend because the lock must outlive any one transaction.

A shard is one primary plus physical replicas (two or more recommended), so all members share a catalog. Separate shards can still assign different OIDs to the same custom type. That breaks clients that read type OIDs off the wire and cache them. Neki's fix is to make one shard authoritative: responses from other shards have their custom-type OIDs translated to match it. The authoritative shard's Sidecar also pushes schema changes such as renames and dropped columns to the Routers.

Control plane and query path

Admin health-checks every Sidecar, tracks replica lag, and runs both emergency failovers and planned switchovers. It uses to bring diverged nodes onto the new primary's timeline. Each shard has a durability policy: async, sync (one replica must confirm), or cross-zone sync (a replica in another availability zone must confirm). Postgres's own synchronous replication enforces it, and Admin keeps the configuration correct as the topology changes. The Kubernetes manages pod lifecycles. For a live instance it builds the replacement and confirms it has caught up before deleting the old one.

B-trees can match an exact value, a range or a prefix. They can't match a word in the middle of a string, so LIKE '%postgres%' ends up scanning every row. Patrick Reynolds' explainer, written as background for PlanetScale's TIN extension, walks through how the alternative works: an inverted index.

Structure and size

An inverted index has two required parts. The term dictionary is often a b-tree or another sorted structure. Wildcard and fuzzy queries scan part of it. It points to postings lists: sorted, compressed lists of document IDs. Dense lists store the gaps between IDs instead of the IDs themselves. Take a corpus of 300,000 documents where 100,000 contain "who." Each raw ID needs 19 bits, but the average gap is 3, which fits in 2 bits. Once about half of all documents contain a term, a bitmap is the best encoding, and SIMD can AND or OR 128 to 512 bits in one instruction. Sorted lists also support union and intersection in a single O(n) pass.

Two parts are optional. Positional data supports phrase and NEAR queries and is stored separately because most queries don't need it. Frequency statistics support BM25 scoring. Each feature adds size:

• No positions or scores: about 20% of the corpus.
• English text with positions and frequencies: 30–50%.
• Code search with overlapping tokens: up to 300%.

Tokenizer choices involve trade-offs too. Stemming lets a search for one form of a word match the others. Dropping stop words shrinks the index, but then it can't distinguish "York" from "New York," and it can't find "The Who" at all.