Tessera

00 The whole system, on one page

Tessera is a tenant-first, Kubernetes-native Postgres. The thesis is a single reversal: instead of carving one big shared Postgres into multiplexed subsystems, we clone a tiny isolated Postgres per tenant — a Cell — and share only the durable plumbing underneath it. Each tenant gets a real, single-writer Postgres process (one OrioleDB-style storage engine, sandboxed in gVisor — a lightweight kernel-emulation sandbox that intercepts the program's system calls so it can't touch the host directly); everyone shares one routing plane (Gateway), one control plane (Conductor), and one durable substrate (Journal → Pagestore → S3). The Cell is stateless compute that can be killed and replayed; the truth lives below it.

Read the diagram in two passes. The solid edges are the data path: a client connects to the Gateway, which authenticates and routes it to that tenant's Cell; the Cell commits writes as a single ordered WAL stream (the write-ahead log — an append-only journal of every change, written before the change is applied, so a crash can always be replayed) into the Journal (durable only once a quorum acks — a majority of replicas must confirm the write before it counts, like requiring 2 of 3 signatures), and reads any page it doesn't have warm in local cache from the Pagestore via getPage@LSN (ask for the contents of a page as of a specific point in the WAL stream — the LSN, or log sequence number, is that point's position), all ultimately backed by S3. The dashed edges are control: the Conductor hands the Gateway its routing table and hands each live Cell a time-bounded epoch lease (a time-limited, numbered grant of "you are the writer right now" — like a relay baton that expires, so a stale holder can't keep writing) that makes it the one and only writer for that tenant — then schedules cells awake and parks idle ones. Control never touches a byte of tenant data.

A few of those headline facts deserve a half-sentence of honesty up front. "$0 compute when parked" is real because a Cell holds no durable local state — kill it and nothing is lost — but waking a cold tenant costs a wake latency (pod schedule + WAL replay), which the Gateway hides by holding the client connection open, Knative-activator style (the request waits at the door while the service spins up from zero, instead of failing). "No vacuum" comes from the OrioleDB-style storage engine (undo-log MVCC — multi-version concurrency control, where instead of overwriting a row each writer keeps the old version aside so readers never block writers + 64-bit transaction IDs): there is no freeze, no autovacuum, no wraparound to manage — the maintenance subsystem doesn't get relocated, it ceases to exist, which is exactly what makes cold-parking free. "Serializable per tenant" is nearly free precisely because each tenant is a single-writer Postgres; the cost is the firm rule that cross-tenant atomic transactions are forbidden in v1.

01 Architecture — the whole system

Read it top to bottom as the data path: a client hits the always-on Gateway, which routes into one tenant's isolated Cell; the cell appends to the quorum Journal, the journal ships committed WAL to Pagestore, and Pagestore serves versioned pages back to the cell while backing everything to S3. Off to the side, the Conductor control plane hands out the single-writer epoch lease, places and parks cells, and pushes the route table — never on the request hot path. Solid arrows are the data path; dashed arrows are control.

02 The core reversal: clone Postgres, don’t carve it

The seductive instinct when you want a "cloud-native Postgres" is to take the monolith apart — peel off vacuum here, the buffer manager there, the lock table somewhere else — and reassemble the pieces as microservices that scale independently. That instinct is mostly wrong, and understanding exactly why is the intellectual foundation of everything Tessera does. Postgres has a handful of subsystems that genuinely cut clean — and a dense core that does not cut at all, because those parts don’t live inside the instance: they are the instance.

Start with the parts that separate cleanly. Four of them already exist as standalone services in the wild, so this is not speculation:

Now the dense core. The transaction manager, the snapshot/visibility horizon (the ProcArray — Postgres’s in-memory list of every live transaction — plus the clog, the commit-status log), the buffer manager, the lock manager, the postmaster process model, and the extension/hook mechanism are effectively inseparable. Not because nobody has tried, but because they all read and mutate the same shared-memory state in the same address space, under the same spinlocks and buffer pins. A backend deciding whether row X is visible consults the live ProcArray snapshot; that decision is meaningless across a network hop because the horizon it depends on moves microsecond to microsecond. Pull any one of these onto its own pod and you don’t get a microservice — you get a distributed consensus problem wrapped around what used to be a pointer dereference, on the hot path of every single query.

The "vacuum as a microservice" myth

This is the trap worth naming explicitly, because it’s the one everybody reaches for first. Vacuum looks like background maintenance — surely it can be a worker pool on its own pods, sweeping dead tuples on a schedule (a dead tuple is the old copy of a row left behind by an MVCC update or delete, dead weight once no transaction can still see it)? It cannot. Vacuum’s correctness depends on the same shared snapshot horizon every live backend depends on: it may only reclaim a tuple version once it proves no running transaction can still see it — which means reading the live ProcArray in this instance. And to physically remove a tuple it must take the per-buffer cleanup lock — an exclusive pin no other backend can hold — page by page, inside this instance’s buffer pool. Both of those are in-process, shared-memory operations. Lift vacuum onto its own pod and it can neither compute a correct horizon nor acquire the pins; it would have to coordinate every reclamation with every backend over the wire. That isn’t a microservice — it’s the coupling, relocated and made slower.

There are only two honest ways out. (a) Dissolve the cleanup into the storage tier — let the page materializer garbage-collect old versions as it compacts, which is roughly what a log-structured Pagestore does. Or (b) eliminate the need for it: swap heap MVCC for an undo-log storage engine (OrioleDB-style, with 64-bit XIDs) so dead versions go to an undo log that’s trimmed inline — no dead-tuple sweep, no freeze, no autovacuum, no transaction-id wraparound (Postgres numbers transactions with a counter that, when 32-bit, eventually runs out and rolls over — risking old rows suddenly looking "in the future"; wider 64-bit IDs make that overflow a non-event). Tessera takes route (b). The maintenance subsystem isn’t relocated; it ceases to exist. forward-ref ch.06 — and it’s precisely this elimination that makes cold-parking a cell truly free, since there’s no freeze-before-park debt to pay.

Read the table top to bottom and the shape of Tessera falls out of it: the clean cuts become the shared substrate, the inseparable core gets cloned per tenant, and the one subsystem nobody can cleanly cut or usefully relocate — vacuum — gets designed out of existence. The diagram below contrasts the two mental models.

03 Anatomy of a Tenant Cell

A Cell is the atom of Tessera: one tenant, one OrioleDB-Postgres process, running inside a gVisor-sandboxed pod (gVisor is a security layer that wraps the process so its low-level OS requests never touch the real host kernel). It is real Postgres — it parses SQL, plans queries, holds the catalog, and loads the tenant's extensions in-process — but it is stateless compute. It owns no durable local state. Kill it, reschedule it, park it cold; it comes back by replaying its WAL (the write-ahead log — an append-only journal of every change, written before the change is applied, so a crash can always be replayed forward). Everything that makes a database "stick to a machine" has been delegated away.

What lives inside, and what does not

A warm Cell holds exactly the state Postgres needs to answer queries fast: the tenant's system catalog and relcache (the in-memory map of tables, indexes, types, and functions), a local page cache on NVMe, and the tenant's extensions loaded as .so objects directly into the backend's address space. That is the whole footprint. None of it is the source of truth — it is all reconstructable. The local NVMe / PVC is a cache, never a home: if it vanishes, the Cell refills it from Pagestore on the next page miss.

The reason a Cell can be this thin is a strict division of labor. The Cell does the CPU-bound, tenant-specific work — parse, plan, execute, hold catalog, run extensions — and delegates everything stateful or shared to the other planes:

That delegation is the entire trick. Because the Cell exports its durability, its pages, its routing, and its authority, the process itself carries no irreplaceable state — which is what makes it disposable.

One cell, drawn

The isolation onion

A Cell runs arbitrary native-C extension code, so it is wrapped in defense-in-depth. The dangerous innermost layer — a tenant-uploaded .so running in-process — sits behind a gVisor sentry that intercepts and reimplements syscalls in userspace, so the tenant's code never talks straight to the host kernel. Read the onion from the host inward:

Extensions that trip gVisor's syscall surface — or tenants who pay for maximum isolation — escalate to a Kata/Firecracker microVM tier, covered in chapter 09.

The honest cost: cold start

Disposability is not free — it shows up at wake time. A cold Cell's first byte is the sum of four serial steps, and you pay all of them on a scale-to-zero hit:

The Gateway hides this latency from the client by holding the connection open while the Cell wakes (the Knative-activator pattern), so the user sees a slow query, not a failed one. Driving each of these steps down — and deciding which tenants get to stay warm — is the subject of chapter 06.

04 The four shared planes

A Tenant Cell is the only thing in Tessera that is per-tenant. Everything a cell needs to exist — to be reached, to be scheduled, to commit durably, to read its pages — is rented from four shared, multi-tenant planes. The split is deliberate: per-tenant where isolation and consistency demand it; shared everywhere that pooling buys efficiency, elasticity, and scale-to-zero economics.

What each plane owns, and why it is shared

Each plane is shared for a different reason. The Gateway must be always-on and addressable even while a tenant is parked — it is the front door that survives cold cells, so it cannot be per-tenant. The Conductor holds one global view of placement, leases, and the extension catalog; consensus only works if there is exactly one of it (logically). The Journal and Pagestore amortize the cost of durable quorum storage (a write counts only once a majority of replicas agree — like needing 2 of 3 signatures) and an S3 page cache across thousands of mostly-idle tenants — running a private 3-node quorum per tenant would be ruinous. The shared planes are how scale-to-zero stays cheap: a parked tenant costs only the bytes its WAL and pages occupy in shared storage, not a running anything.

Four planes at a glance

05 Life of a query — warm and cold

A query in Tessera takes one of two paths depending on whether the tenant's Cell is already running. When the Cell is warm the path is an ordinary Postgres round-trip with one twist: durability is a quorum ack (a majority of copies must confirm the write before it counts — like needing 2 of 3 signatures) on the commit path. When the Cell is cold (parked to save money), the Gateway quietly holds the client socket while the Conductor wakes the Cell — and the Cell replays its WAL (the write-ahead log — an append-only journal of every change, written before the change is applied, so a crash can be replayed) up to the committed point before it answers, so a wake never serves stale data.

Warm path — the Cell is already running

The client connects to the always-on Gateway, which terminates TLS, authenticates with SCRAM-SHA-256, looks up which Cell owns this tenant_id, and forwards bytes to that Cell. The Cell parses, plans, and executes. Reads hit the local page cache on NVMe (a cache, never the source of truth); on a miss it pulls the exact version it needs with getPage@LSN (fetch a page as of a specific LSN — a log sequence number, the monotonic position in the WAL that names a point in time) from the Pagestore. On COMMIT the Cell ships the WAL record to the Journal and waits for a quorum (majority) ack before telling the client the commit succeeded. That wait is the throughput we deliberately spend for durability — the record is on a majority of safekeepers before the client believes it.

Cold path — the Cell is parked

If the tenant has been idle, its Cell is scaled to zero — no pod, no compute cost (cold-parking is free because the OrioleDB engine has no vacuum/freeze backlog to settle first). At routing time the Gateway sees no live Cell. It does not error: it holds the client connection open (the Knative-activator trick) and signals the Conductor to wake the tenant. The Conductor schedules a pod and grants the single-writer lease — an epoch/term fence (each grant gets a higher number; writes stamped with a stale number are rejected, so a slow old Cell can't clobber the new one) so exactly one Cell may write this tenant's stream. The Cell starts, asks the Journal for the latest quorum-committed LSN, and replays WAL up to that LSN before accepting any query. Only then does the Gateway forward the connection it was holding. The client saw extra latency, never an error or stale read.

Where the latency goes

The warm path adds only a Gateway hop plus, on commit, one quorum round-trip. The cold path stacks pod scheduling and WAL replay on top of the first query of a parked tenant — a one-time tax paid by the request that triggers the wake, then amortized away while the Cell stays warm.

06 Scale-to-zero & the cold-tenant problem

A reader's first instinct is to scale-to-zero the table they only touch once a month. But Postgres is process-per-instance, not per-table — you cannot freeze one relation while its siblings stay hot in the same backend. That is exactly why tenant = one isolated Postgres cell: the unit you can actually take to zero is the tenant's compute, not a table inside a shared instance. Park a rarely-used tenant and its cell pod simply disappears — $0 compute while its storage sits, untouched and durable, in the Journal and S3.

The lifecycle state machine

A cell moves through four states. The Conductor (control plane) owns every transition: it grants the single-writer epoch lease (a time-limited permission to be the one writer, stamped with a version number — like a numbered hall pass that expires, so a stale holder is easy to reject) on wake, and revokes/expires it on park. Durable state never moves — only compute appears and disappears.

• Active — pod scheduled, lease held, catalog/relcache warm, serving queries.
• Idle — a grace period after the last query. The pod is still warm; a returning query skips cold-start entirely. This buffer prevents thrash for bursty tenants.
• Parked — grace expired. Conductor revokes the epoch lease (so the Journal will fence any zombie writer — fencing means actively blocking a stale process from writing once its lease is gone, instead of trusting it to notice and stop) and tears down the pod. Compute bill = $0; the tenant's bytes live on in S3.
• Waking — a connection arrived. Conductor schedules a fresh pod, grants a new epoch lease, and the cell replays WAL forward to its last committed LSN (log sequence number — a monotonic byte-offset address into the WAL, like a page number marking exactly how far the log was replayed) before accepting traffic.

The Gateway hides the wake from the client using the Knative-activator trick: it holds the open client connection — TCP established, the client just waits — while the cell wakes, then splices traffic through once the cell reports ready. Below the hold-timeout this looks like a slow first query, not an error.

Why parking is genuinely free

Here is the load-bearing point, and it is about vacuum (Postgres's background cleanup that reclaims space and resets row bookkeeping), not about pods. On a stock Postgres heap, transaction-id (XID) wraparound advances with global commit volume across the whole instance — every transaction gets a 32-bit ID, and that counter can run out and wrap around like a car odometer rolling over; old rows must be "frozen" before that happens or data looks like it's from the future — the 32-bit XID space is consumed by activity anywhere. A parked tenant cannot opt out of time: as the rest of the fleet commits, its un-frozen tuples drift toward the wraparound horizon. Eventually anti-wraparound autovacuum must run on those tables, which means a parked tenant would be forced awake (or the system force-shuts-down to protect data). The only stock defense is a VACUUM FREEZE ritual before every park — turning "free parking" into "scan-the-whole-tenant-first parking," which is exactly the cost that kills the economics for big, cold tenants.

The honest cost: cold-start

Free parking does not mean free waking. A cold wake pays a sequential budget, and big-schema tenants have a worse tail.

07 Storage, MVCC, and the death of vacuum

This is the meaty floor of Tessera: how a row version is kept, and where bytes actually live. Two moves combine. First, an OrioleDB-style storage engine deletes vacuum outright rather than relocating it. Second, the cell is made stateless — durability and page materialization move outside the Postgres process into the Journal and Pagestore. The payoff is a clean fit: OrioleDB's S3 storage is single-writer-per-namespace, which is exactly Tessera's single-writer-per-tenant rule. The ambitious engine and the locked consistency model are the same shape.

Why vacuum exists — and why it can simply stop existing

Stock Postgres uses heap MVCC (multi-version concurrency control — each writer makes a new copy of a row instead of overwriting it, so readers never block writers): an UPDATE or DELETE does not overwrite or remove the old row, it leaves a dead tuple in place and writes a new version next to it. Dead tuples accumulate inside the table (bloat), so a background process — autovacuum — must crawl the heap to reclaim that space and to freeze old rows before the 32-bit transaction id (XID) counter wraps around. Wraparound is a hard correctness cliff: miss the freeze deadline and the database shuts down to avoid losing data. That entire machine — autovacuum workers, freeze, the wraparound clock — is maintenance that the heap design forces on you.

OrioleDB-style undo-log MVCC inverts it. The current row version lives in the table; old versions are written to a separate undo log, not parked in the heap. A transaction that needs an older snapshot walks the undo chain; once no snapshot can see a version, the undo space is reclaimed by simple log truncation — no full-table scan to hunt dead tuples. Pair that with 64-bit XIDs and the wraparound clock effectively never rings. Net: no vacuum, no freeze, no autovacuum workers, no bloat-driven maintenance. The "is vacuum its own subsystem?" question is answered by deletion, not relocation — and that is precisely what makes cold-parking free: there is no freeze-before-park step (forward-ref to ch06 scale-to-zero).

Disaggregation: the cell holds no truth

A Tenant Cell is stateless compute. Its local NVMe is a cache, never the source of truth — truth is the WAL stream (the write-ahead log — an append-only journal of every change, written before the change is applied, so a crash can always be replayed) in the Journal plus materialized pages backed by S3. That separation is what lets a cell be killed, parked, or rescheduled and recover by replaying WAL. The write path is a single ordered hand-off; the read path is a page fetch keyed by log position (LSN).

On commit the cell only needs the Journal to durably accept the WAL by majority quorum — page materialization is asynchronous and lives downstream in the Pagestore, which replays committed WAL into versioned pages and spills them to S3. Reads ask the Pagestore for a specific page at a specific LSN; a local NVMe hit is fast, a miss rehydrates from S3. The cell's RAM still holds the hot working set plus the tenant's catalog and relcache while warm, so a steady-state query rarely leaves the box.

The honest tension

Crucially, the bet is hedged at the architecture seam, not the application surface. Everything above — disaggregated WAL into a quorum Journal, a Pagestore that materializes versioned pages, S3 as bottomless truth, single-writer fencing (a guarantee that a deposed or stale writer is hard-blocked from the storage so only one cell can ever write — like changing the locks so the old keyholder is locked out) — is engine-agnostic. If OrioleDB blocks (a beta sharp edge, a format break, a missing capability), Tessera keeps the same disaggregated shape on stock heap plus a Neon-style pageserver. The only thing lost in that fallback is the headline "vacuum is literally gone": you would carry autovacuum and freeze again, with the wraparound clock back on the wall. That is the failure mode tracked under risks in ch15 — a graceful degradation to a proven design, not a redesign.

08 Consistency, durability & no split-brain

This is the reliability heart of Tessera. The locked stance is blunt: throughput may bend, but consistency and durability may not. The tenant-first frame is what makes that affordable — because each tenant is a single isolated Postgres cell with exactly one writer, the hard parts of distributed databases (a global snapshot oracle, distributed timestamp ordering, cross-shard commit) simply never appear at the tenant boundary.

Per-tenant serializable, for free

The tenant is the hard transaction boundary, and a tenant has a single writer — its one warm cell. A single Postgres process already ships Serializable Snapshot Isolation (SSI), the optimistic protocol that detects read/write dependency cycles and aborts the loser. With one writer there is exactly one logical timeline, so SSI gives true serializability and read-your-writes (a query always sees the writes you just made — no lagging replica can hand you a stale copy) with no coordination beyond what stock Postgres already does inside a single backend. We do not build a distributed snapshot oracle, a global clock, or an HLC — there is nothing to globally order. The cost of a conflict is a transaction abort the client retries; the cost we accept is that a tenant is capped at one writer's throughput (vertical, not horizontal). That cap is the deliberate price of "serializable for free."

Durability via Journal quorum

A commit is not acknowledged to the client until that transaction's WAL records (the write-ahead log — an append-only journal of every change, written before the change is applied so a crash can always be replayed) are majority-committed (more than half the replicas must persist the write before it counts — like requiring 2 of 3 signatures) across the Journal's replicas (the Neon-safekeeper / Aurora-quorum pattern: append to N, ack at ⌈(N+1)/2⌉). With three replicas, two durable copies must persist the LSN (log sequence number — a monotonic byte-offset that names a position in the WAL stream) before COMMIT returns. This survives the loss of any single Journal node and any single cell, because the truth of "what committed" lives in the quorum, not on the cell's local disk — the cell's NVMe/PVC is a cache, never the source of durability.

Single-writer invariant & logical fencing

The whole scheme rests on "exactly one writer per tenant." Conductor enforces it with a monotonic epoch (term) lease — an ever-increasing version number on "who is the writer right now," much like a numbered ticket where only the highest number is honored: when it schedules a cell to own a tenant, it stamps that cell with epoch N. The Journal records the highest epoch it has seen for that tenant's stream and rejects any append carrying a stale epoch. On suspected cell failure — missed heartbeat, network partition, slow pod — Conductor does not need to physically kill the maybe-dead pod (which it may be unable to reach). It simply bumps the epoch to N+1 and hands the lease to a fresh cell. The moment the new cell does its first quorum-accepted write at N+1, the Journal's high-water epoch is N+1, and the old cell's appends at N are refused.

Cold-start correctness

The fence prevents two cells from writing; one more rule prevents a freshly-woken cell from reading stale. A cell that wakes from cold-park (or takes over a fenced tenant) MUST replay WAL up to the Journal's quorum-committed LSN before it serves a single query. It pulls committed WAL from the Journal and pages from Pagestore, advances its applied-LSN to the durable high-water mark, and only then opens to clients (Gateway holds the connection meanwhile, per Chapter on routing). This one rule closes both failure modes at once: a resumed cell can never serve a read older than the last acknowledged commit (no stale read), and because it adopts the latest epoch on takeover, it can never resurrect a fenced predecessor's timeline (no split-brain).

What we forbid in v1

The guarantee ledger

09 Extensions: arbitrary, native, contained

The headline-hard requirement — let any tenant install any extension, including arbitrary native-C code — stops being terrifying the moment each tenant is its own isolated cell. A bad .so (a shared object — a chunk of compiled native code loaded into a running process, the Linux equivalent of a Windows .dll) can only break the one Postgres process that loaded it. Its blast radius is the tenant's own database, never a neighbor's. That single property is what turns "untrusted native code in production" from a non-starter into a routine feature.

Two delivery paths

Install / load decision

Containment: the isolation onion

The default sandbox is gVisor — a userspace kernel (the "sentry") that intercepts the cell's syscalls (the calls a program makes to ask the OS kernel to do something privileged — open a file, send a packet, allocate memory) and services most of them itself instead of passing them to the host kernel. A malicious or buggy .so therefore cannot reach the host kernel, the Pagestore/S3 tier, the Conductor, or any other tenant. The only thing it can touch is the Postgres backend it lives inside — its own cell.

The escape hatch: microVM escalation tier

When a tenant's extension trips gVisor's syscall surface — or simply demands maximum isolation — the Conductor reschedules that tenant's cell onto a Kata / Firecracker microVM: a lightweight VM running a real Linux kernel under hardware virtualization. Full syscall compatibility (it's an actual kernel, so io_uring and friends just work) plus stronger hardware-virt isolation — paid for in higher per-cell cost, lower density, and a slower cold start. gVisor stays the default for density and wake speed; the microVM is the compatibility-and-extra-isolation tier you escalate into, not the baseline.

Operational guardrails

Containment is not only the sandbox. Three guardrails apply to every cell regardless of tier, so an arbitrary extension can't quietly become an exfiltration or cost problem.

10 Security: authn, authz, blast radius

Tessera's security model is a consequence of its architecture, not a layer bolted on top. Because every tenant is its own isolated Postgres cell — its own process, its own keys, its own network identity — isolation is not a feature you configure; it is the shape of the system. The job of this chapter is to make that containment explicit: who proves identity, who is allowed what, what a single breach can reach, and which component you must protect hardest.

Defense in depth — five concentric layers

Each layer assumes the one outside it may have failed. An attacker who defeats the edge still hits a default-deny network; one who defeats the network still lands in a syscall-filtered sandbox; one who escapes the sandbox still reaches data encrypted under a key they do not hold.

Identity & authentication

The Gateway is the only component that ever sees a raw client connection. It terminates TLS, runs SCRAM-SHA-256 (challenge-response, so the password never crosses the wire), and resolves the tenant from the verified identity before routing. Enterprise tenants can layer mTLS (client presents a certificate) or delegate to an external OIDC identity provider — both validated at the edge so a cold cell never has to handle untrusted handshakes during wake. All credentials and signing material live in a secret store and arrive as injected environment values; nothing sensitive is baked into an image or committed to code.

Authorization & the no-superuser-surface win

Inside a cell, authorization is ordinary Postgres: per-tenant roles, GRANTs, row policies — but scoped to a database only that tenant occupies. The subtle, structural win is what is absent. In shared multi-tenant Postgres, a privileged hook (e.g. a pg_tle clientauth/passcheck callback) runs cluster-wide as superuser, so one tenant's malicious hook can intercept every tenant's logins. In Tessera each cell's superuser is scoped to that one isolated instance. There is no cluster-wide hook plane to hijack — the escalation target simply does not exist. The Conductor's own control-plane API is itself authenticated and least-privileged: it issues fencing leases (a time-limited token that crowns exactly one writer — like a baton only one runner may hold, so a stale ex-leader can't keep writing) and placement decisions, and nothing else can.

The path a request is forced to take

Data at rest — crypto isolation

The Pagestore writes every page and WAL segment to S3 under per-tenant envelope encryption: a per-tenant data key encrypts the bytes, and that key is itself wrapped by a root key in a KMS. Decryption authority is therefore scoped per tenant. An object accidentally exposed, an S3 ACL misconfigured, or a backup copied to the wrong bucket all degrade to "ciphertext for one tenant" rather than "plaintext for everyone." Crypto isolation is the backstop for the failure modes that bypass the network and process layers entirely.

Threat register — what each attack can actually reach

11 The Kubernetes object model

Tessera is not "Postgres that happens to run in a pod." It is a small set of custom resources reconciled by an operator. Two CRDs carry all desired state — Tenant (what the customer asked for) and Cell (a concrete running or parked instance of that tenant) — and the Conductor's job is to make the cluster match them. Everything else is a deliberate choice of which stock Kubernetes object best fits each plane's failure model.

The Conductor is a Kubernetes operator — a reconcile loop watching Tenant and Cell objects — backed by a consensus store (etcd/Raft — a cluster of nodes that vote on every change so a majority always agrees on one official answer) that holds the things Kubernetes' own object store is too weak to hold safely: the single-writer epoch leases (the fence that guarantees exactly one writer per tenant), topology, and placement decisions. The K8s API server stores intent; etcd stores the facts that must be linearizable (every reader sees the latest write — no stale answers, as if there were one global clock).

Why each object, not a generic one

Cells are operator-managed Pods — not a vanilla StatefulSet. (A StatefulSet is K8s' built-in way to run pods with stable, numbered identities and their own attached disks — think a fixed roster of named players rather than interchangeable workers.) Following the CloudNativePG pattern, the operator owns each pod's identity directly: it decides the name, the node, the lease epoch, and when the pod dies and is replaced. A StatefulSet's ordinal-and-template model is too rigid here — a tenant's cell is launched, parked to zero, rescheduled onto a different node, and woken under a fresh epoch, and the operator needs to drive each of those transitions explicitly while handing out the single-writer fence. The cell holds no durable local state (local NVMe is a cache; truth is Journal + S3), so the pod is disposable: kill it and it recovers by replaying WAL (the write-ahead log — an append-only journal of every change, written before it is applied, so any crash can be replayed forward).

RuntimeClass is the sandbox lever. Each Cell pod sets runtimeClassName — gvisor by default (the user-space kernel that intercepts syscalls for arbitrary native-C extensions), or kata for the escalation tier (a real microVM for extensions that trip gVisor's syscall surface or need maximum isolation). The Conductor picks the class per cell from the Tenant's extension set, so isolation strength is data-driven, not baked into one cluster-wide runtime.

The durable planes get the stock objects whose semantics already match. The Gateway is a stateless Deployment + HPA — an always-on front door that genuinely is a load-balanced pool, exactly what HPA is for. The Journal is a StatefulSet: WAL durability needs quorum members (a write only counts once a majority of replicas agree — like needing 2 of 3 signatures) with stable network identity and durable PVCs (PersistentVolumeClaims — a pod's request for a disk that survives the pod being killed) so a restarted safekeeper rejoins as the same voter. The Pagestore is also a StatefulSet, its PVCs holding the NVMe page cache that fronts S3 — stable identity lets a restarted pagestore reuse its warm cache instead of re-fetching from object storage. The four control-plane workers — placement, park/wake, catalog + signing, and the orphan-claim reaper — are plain Deployments: stateless reconcilers that read truth from etcd.

12 The tradeoffs ledger

Every choice in this blueprint is a bet, and an honest bet has a bill. This chapter puts the whole bill on the table at once. The stance is not "we are fast and consistent and cheap" — that is a lie every database tells. The stance is narrow and deliberate: throughput and speed may be sacrificed; consistency and reliability may not. Tessera spends raw single-tenant write scale, cross-tenant atomicity, warm density, and tail latency on purpose, in exchange for guarantees it refuses to bend. What follows is the ledger — and, importantly, why it is a coherent bet rather than a pile of unrelated compromises.

Why these spends are one bet, not seven accidents

The tenant-as-isolated-cell decision is the keystone, and almost every cost below is its shadow. A single-writer cell is what makes serializability free — and the same single writer is exactly why there is no intra-tenant write scale-out. Per-tenant Postgres processes are what make arbitrary native-C extensions and scale-to-zero possible — and the same per-process isolation is what makes warm density worse than schemas-in-one-database. Parking a cell to $0 is what crushes the long-tail bill — and the same parking is what creates the cold-start tail on the first query back. You cannot keep the wins and refund the costs; they are the front and back of the same coin. That is the test of a real design: the sacrifices are load-bearing, not lazy.

The ledger: what we sacrifice, to gain, and how we blunt it

A sacrifice with no mitigation is a flaw; a sacrifice with a named mitigation is a design. Each row pairs the cost with what it buys and the specific mechanism that keeps the cost from becoming a wound.

The shape of the bet in three numbers

Where the bet could be wrong

Honesty cuts both ways. Three edges are worth naming plainly. First, OrioleDB is beta — the entire no-vacuum win rides on a storage engine that has not been battle-hardened at the scale a multi-tenant platform implies; the mitigation (S3 as engine-independent truth, a standard-Postgres fallback) is real but not free to exercise. Second, cold-start tail latency is a felt cost, not a hidden one — a user hitting a parked tenant after a long idle will wait for wake + replay; we make that wait correct and bounded, but we do not make it zero. Third, the single-writer cap is a hard ceiling for a genuinely write-heavy mega-tenant — vertical scaling and read replicas push it out, but a tenant that needs sharded writes is, by design, not a fit for v1. None of these are accidents. They are the agreed price of a database that will not lie to you about consistency or durability — and naming them is what makes the bet trustworthy.

13 Build vs. borrow

Here is the reassuring headline before the roadmap: almost nothing in Tessera is genuinely from scratch. The overwhelming majority is integrating battle-tested open source. The real novelty is concentrated in exactly one property — sandboxed self-service native extensions — plus the welding that fuses the proven parts into one tenant-first lifecycle. Every box below is sorted into one of three buckets.

The roadmap, next, sequences this so the borrowed pieces land first (cheapest, highest-confidence) and the two from-scratch pieces come last — by which point everything they depend on is already standing.

14 How you’d actually build it

A blueprint is only buildable if it has a build order. This is the one we’d ship — phased so each step de-risks the next and proves a load-bearing claim before the next claim depends on it. The ordering principle is blunt: the riskiest, highest-ROL component goes first, and the first thing that is genuinely hard and genuinely reusable is WAL-durability-as-a-service (the WAL, or write-ahead log, is an append-only journal of every change — written before the change is applied, so a crash can always be replayed). Everything else (statelessness, scale-to-zero, extensions) is bought by the disaggregation that the Journal forces into existence.

The staircase

Each phase below states what it de-risks — the single claim it exists to prove — so you can stop, ship, and learn at any step rather than betting the whole design on a big-bang integration.

Why this order, in one picture

The dependency chain is almost linear: durability (P1) is what lets you trust a remote page store (P2); statelessness (P2) is what lets you park and reschedule (P4); a connection-holding Gateway (P3) is what hides both reschedule and cold-wake latency from the client; and only once a tenant is a disposable, sandboxable unit do arbitrary extensions (P5) become safe to offer.

15 Where this is genuinely hard

A blueprint that only lists wins is a brochure. This chapter is the risk register: the seven places Tessera is actually hard, ranked by how much they can hurt, each paired with a mitigation we can build and — where one exists — a fallback that costs us a feature but not the architecture. Two are sharp enough to flag in red. The honest summary at the end: every constituent piece is proven in production; the novelty (and therefore the risk) is the combination under a strict tenant-first, consistency-first frame.

The risk register

Which risks threaten correctness vs. cost

It matters where each risk lands. Only one — the Conductor — can threaten the core consistency invariant; the rest threaten footprint, latency, or unit economics, which we are explicitly allowed to spend (Ch. 07's stance: throughput and cost may bend, consistency may not). The OrioleDB bet is unusual: it threatens neither correctness (the fallback engine preserves every guarantee) nor cost directly — it threatens maturity, which is a schedule-and-operations risk you buy down with testing and version discipline.

Honest verdict

Pull the design apart and every load-bearing piece is individually proven in production: Neon ships safekeepers (the Journal pattern) + a pageserver (the Pagestore pattern) + scale-to-zero at scale; OrioleDB ships a working no-vacuum, undo-log storage engine; gVisor runs untrusted code under hostile multi-tenancy at Google scale; CloudNativePG and Knative prove the operator + activator model that the Conductor and Gateway lean on. None of these is speculative. The genuine novelty — and the genuine risk — is the combination: assembling them under a strict tenant-first, consistency-first frame where a tenant is one isolated cell, the writer is fenced by epoch, and the storage engine has erased vacuum. That synthesis has not been built before in exactly this shape. It is ambitious. But it is grounded: the parts are real, the invariants are precise, the fallback for the riskiest bet (OrioleDB) costs one feature and zero correctness, and the one component that can break consistency (the Conductor) is named, isolated, and assigned to be hardened. Ambitious, not hand-wavy.

16 Plain-language glossary

Every piece of jargon in this blueprint, gathered in one place — one plain sentence each, with an analogy where it sharpens. Skim it once, or jump back here whenever a term in an earlier chapter trips you up. Nothing here is new architecture; it is purely a decoder ring for the vocabulary the rest of the document leans on.

Postgres internals

Consistency & durability

Isolation & sandboxing

Kubernetes & infrastructure