Choosing the least-regret tenancy model

When the first paying users arrived, we noticed three obvious ways to share Postgres:

• Row-level multitenancy looked cheap but came with shared-statistics nightmares and the ever-present risk of one tenant’s bad query affecting everyone else.

• Schema-per-tenant felt tidier until you tally up extension drift, pg_namespace bloat and global locks that turn ordinary DDL into a convoy.

• Database-per-tenant promised hard isolation.

We picked the last option and parked roughly eighty to a hundred tenant databases on a single RDS instance. (We run several of these instances, but the exact count is private.) We briefly considered a physical Postgres per tenant model—true single-tenant servers—but the economics were brutal for smaller customers, and nothing in our workload justified that burn.

What the catalog actually stores

Because PeerDB merely coordinates data movement, not the data itself, the catalog is light. Every write is either metadata (a new pipeline, a rotated secret) or a counter that jumps once per batch moved. We store those counters already rolled-up so queries stay fast; the hottest table is still well under twenty-five gigabytes. If growth ever forces sharding, we’ll know long in advance, and until then we enjoy the luxury of Postgres doing exactly what it has done well for decades.

Shipping changes without roulette

Our schema lives in a refinery migrations folder. During an upgrade the Kubernetes init-container for each service runs the pending migrations against its tenant databases and holds an advisory lock so one long migration can’t block its neighbors. The process is deterministic, self-healing, and—best of all—boringly repeatable.

Observability

We began with Datadog; the swipe-your-card convenience was unbeatable, right up to the moment the bill wasn’t. Today our observability is powered LogHouse and LightHouse.

What has worked in practice

First, a tiny fleet is easy to watch: a couple of RDS dashboards and a Grafana page tell us everything. Second, deep Postgres expertise pays compound interest. When a query plan misbehaves, someone on the team has already debugged that planner corner case in a past life. Third, our open-source posture matches the model; the public PeerDB repository assumes exactly this catalog layout, so what we dog-food is what we ship.

The trade-offs we live with

Postgres connections are fat. In the early days, before we sized instances correctly, we lived in fear of exhausting the pool. Connection pooling and right-sizing bought back margin, but it was a lesson learned the noisy way. And while automation is good, wrangling hundreds of logical databases remains real work—from permissions audits to extension upgrades, there is no perfect autopilot yet.

Still the best deal in town

Could we outgrow this design? Sure—success comes with new scaling puzzles. But the catalog will tell us long before anything combusts, and the escape hatches (read replicas, horizontal shards, even separate servers for large tenants) are well-trodden Postgres terrain. Until that day, every new PeerDB-Cloud customer gets a freshly minted logical database, a clear blast radius, and the quiet confidence that boring infrastructure lets the interesting work happen elsewhere.

See you in the next piece,
Kaushik

I’m Kaushik Iska — software engineer, YC-founder, CTO of PeerDB (acquired by ClickHouse), ex-Flutter contributor, and parent to energetic twin toddlers. Over the years I’ve filled private notebooks with database oddities, GPU experiments, and performance war stories. Friends kept nudging me to put the interesting bits somewhere public.

Why now? Honestly—why not now? The infrastructure world feels especially exciting: lot of changes and lot more momentum in every area of software development. I have a backlog of side projects I want to talk and share about.

What to Expect

• Architecture case notes from PeerDB, ClickHouse, and weekend side projects—including the dead ends and rollbacks.

• Deep-tech essays on Postgres internals, golang oddities, GPU pipelines, distributed tracing, and the small algorithmic tricks that turn works into fast.

• Reflections on balance: building systems while raising twins and staying (mostly) sane.

I’ll post roughly once a month. Rather than dumping raw code, I’ll focus on the thought process—trade-offs, mental models, and lessons learned.

See you in the next piece,
Kaushik