DEV Community: Suraj Upadhyay

PostgreSQL Multi-Tenancy: Isolation That Survives a Growing Team

Suraj Upadhyay — Fri, 28 Aug 2026 06:47:41 +0000

Startups building B2B products reach for multi-tenancy in PostgreSQL the same way on day one: one shared database, one set of tables, and a tenant_id column marking who owns each row. That is the correct call, and it stays correct for a long time. However, when that column is enforced by application code rather than by the database, a single forgotten predicate stops being a bug and becomes a disclosure event, and a disclosure event is one of the very few engineering failures that lands straight on your balance sheet as stalled enterprise deals, an unplanned legal bill, and a security review you can no longer pass. By understanding what multi-tenancy actually guarantees, which isolation model fits your stage, and how Row-Level Security moves that guarantee out of your codebase, startup CTOs and Fractional CTOs can make the tenant boundary hold without slowing the team down.

(If you want to skip the theory, jump straight to the connection pooler trap that switches Row-Level Security off in production, what it costs in query performance, or when it is genuinely time to leave the shared schema.)

Because "enforced by application code" means something very specific in practice. It means a promise that everyone will remember to filter on tenant_id, and that promise is the single most expensive line of undocumented policy in your entire codebase, because it holds perfectly for about fourteen months, right up until the afternoon a tired engineer ships a reporting endpoint that joins four tables and forgets the predicate on exactly one of them, and then a customer opens a dashboard and sees somebody else's invoices.

That is not a bug. A bug is something you fix on Monday. A cross-tenant data leak is a disclosure event, which means legal gets involved, your enterprise prospects get an email from their own security team, and the deal that was supposed to close your Series A quietly moves to next quarter and then to never.

The uncomfortable part is that this is not a story about careless engineers. It is a story about an architecture that requires every engineer to be careful forever, which is not an architecture at all, it's a hope.

What is multi-tenancy in PostgreSQL?

Multi-tenancy in PostgreSQL is the practice of serving multiple customers, called tenants, from a single database system while guaranteeing that no tenant can read or modify another tenant's data. PostgreSQL supports this at three levels of physical separation: a shared schema where a tenant_id column marks ownership of each row, a separate schema per tenant, or a separate database per tenant.

The word doing all the work in that definition is guaranteeing. Any database can store several customers' rows in one table. What distinguishes a real multi-tenant architecture is where the guarantee lives, either in application code that every engineer must remember to write, or in the database itself, where it holds whether or not anyone remembered.

PostgreSQL has shipped a mechanism for the second option since version 9.5, in 2016. It is called Row-Level Security, and most of this post is about using it without stepping on the three mines buried around it.

The three isolation models, and what each one really costs

There are exactly three shapes here, and every vendor blog that tells you otherwise is selling something.

	Shared schema + `tenant_id`	Schema per tenant	Database per tenant
Separation	Logical, by column	Logical, by namespace	Physical
Cost per tenant	Near zero	Catalog rows, real at scale	An instance
Migrations	One run	A loop over tenants	A loop over instances
Cross-tenant analytics	A query	A fan-out job	A pipeline
Noisy-neighbour control	None	None	Full
Restore one tenant	Hard	Moderate	Trivial
Enforcement	RLS, or app code	Namespace + `search_path`	Connection string
Choose this when	Default. Almost everybody.	Tenant schemas genuinely diverge	A named customer or a residency law demands it

Most startups pick the shared schema correctly and then defend it incorrectly, which is a distinction worth sitting with, because the shared schema really is the right default for almost everybody reading this. You should not be running a schema per tenant at eleven customers, and the founder who spent a quarter building a database-per-tenant provisioning pipeline before finding product-market fit has bought a very good insurance policy on a house he has not finished building.

The mistake is not picking the shared schema. The mistake is enforcing it in application code.

How Row-Level Security actually works

Row-Level Security is a PostgreSQL feature that attaches a boolean policy to a table, which the planner then welds onto every query touching that table, so that rows failing the policy are invisible regardless of what the query asked for. A missing WHERE tenant_id = ... stops being a data leak and starts being an empty result set, which is a category of failure your QA process can actually
catch.

To read the full articles you can visit 👉 PostgreSQL Multi-Tenancy: Isolation That Survives a Growing Team

I write about startup systems architecture at
esence.io. If your tenant boundary is currently held together by code review, that is the kind of thing I look at for a living.

Why Startups should only hire a Fractional CTO instead

Suraj Upadhyay — Wed, 08 Jul 2026 18:30:00 +0000

Tech Leadership hiring is a strategic, inevitable and deeply financial decision

Designing an Engineering Team as a Founder is more important than your
Engineering Team designing your system or your product. I have worked with a
couple of startups and have seen a common pattern -

A non-technical founder having an idea and a figma file hires a couple of
engineers, builds a great product, sees some success in the market or closes an
institutional Seed or Series A round and ends up hiring a CTO with 18 years of
experience to lead the engineering team that has built the product.

This new full-time CTO having a brilliant career graph of 18 years, being a
principal or a staff engineer in a distinguished Company starts on his new role
feeling utterly clueless on how startups actually work. He starts by analyzing
the codebase and the current architecture of the product, and finds major flaws
in how the product is actually implemented, he begins by pointing out that many
of the best principles aren't followed and the whole codebase is tightly coupled
and making changes is a nightmare.

He immediately creates tens and hundreds of Jira tickets and dictates the
engineering team to finish them before building any other major features. And he
does all this by sending emails and meeting once or twice in a couple of days,
barely joining standup calls, because that's what he is used to.

The engineering team accustomed to the fast-paced nature of startups finds it a
bit more difficult to actually write good quality code that would satisfy
an industry veteran, but still delivers in a record time. To them, it was the
biggest learning curve of their entire lifetime, but our veteran is still not
satisfied and stalls your feature roadmap to force an abstract architectural
rewrite.

Time passes by, and you as a founder start seeing stagnancy in your
organization even after burning precious runway on massive executive
compensation packages for the engineering team, but don't know what exactly
went in the wrong direction since all the reasoning given by our veteran seems
fool-proof and unavoidable.

If this story sounds familiar or you are going through something similar, then
let me tell you that it happens to the best of ambitious founders but it can be
solved through strategic hiring and re-assessing your leadership needs.

Here's what experience and seasoned serial entrepreneurs do instead -

Hire a Fractional CTO!

Why you should hire a Fractional CTO

There's a huge difference between hiring an engineer and hiring engineering
leadership like a CTO, a Staff Engineer or a Software Architect.

When you hire a developer, you are paying for execution output. When you hire a
CTO, you are making a structural bet on the trajectory of your product, your
cap table, and your company's operational burn rate.

An early-stage startup does not need an 18-year corporate veteran sitting on a
full-time salary to manage four developers. They need elite architectural taste
delivered in high-impact, concentrated bursts.

They need a Fractional CTO. Here is exactly why:

1. The Paradox of the "Enterprise Blueprint"

An enterprise executive’s instinct is to minimize risk through process,
bureaucracy, and heavy administrative compliance frameworks. In a startup,
your greatest risk isn't a minor system drift, it's moving too slow and
dying before you find product-market fit. A Fractional CTO builds minimalist,
flexible foundations that allow your team to pivot instantly without getting
trapped under 400 unresolved Jira tickets.

2. Radical Runway Frugality

Let’s talk numbers. A high-caliber, full-time CTO demands massive cash
compensation, heavy equity grants, and expensive corporate benefits. For a
startup, that is an incredibly heavy liability to carry on day one. A
Fractional CTO gives you access to elite, battle-tested architectural
governance at a fraction of the overhead cost, allowing you to preserve
capital and deploy your cash directly into hiring raw, high-output execution
developers instead.

3. Execution-Focused Mentorship

...

You can read the full article on my blog - Engineering Insights at Esence.io

Scaling Codebases Without Platform Bloat

Suraj Upadhyay — Wed, 01 Jul 2026 04:19:00 +0000

Redundant compilation lags, bloated CI pipelines and version drift for internal
modules quietly drain developer velocity. And normally, it's too late when the
leadership gets the whiff of it. According to recent studies, the hidden tax on
your team looks exactly like this -

The Direct Time Drain: Your engineers waste an average of 25 to 50 minutes
due to compilation lags.
The Redundant Build: An engineer wastes his valuable time rebuilding
something that already exists and is being used in another team.
The Pipeline Blocker: Your Frontend Team spends an entire sprint cycle
completely idle, waiting for the Core Platform Team to version-tag and publish
the latest approved button changes.

All these, as bad as they sound, are common occurrences in the majority of
software engineering teams trying their best to ship fast and iterate faster.
The problems that I listed are not inevitable, and can be solved if we just
carefully design our engineering culture and the codebase that it revolves
around from the beginning.

In today's edition, let's tackle them one-by-one and continue where we left off
last time in our adventure of building
the ideal monorepo setup for
startups.

Assuming that you followed my advice of having a monorepo for all your codebase
needs for your startup, let's hit the road!

The Redundant Build: A guide to module re-use

While there's no sure-shot way of knowing what an engineer thinks before
embarking on the painstaking journey of rebuilding the wheel, we can mitigate
the risk through some primary cautions -

Build a collection of re-usable modules.
Business logic must never be allowed to be repeated.
Engineers should learn about the existing system for their use-case.

Though I know, forcing software engineers to do something they don't approve of
is never a good idea. But Companies and Team Leads should force these elementary
coding principles rigorously via code-reviews and documentation.

Building a Collection of Reusable modules

Startups that successfully keep growing, also tend to constantly rebuild many
parts of their system again and again. To give you a few examples -

UI Components: The same kind of button, the same navigation bar, the same
sidebar nav, etc. are rebuilt across different product lines to keep the look and
feel of the brand consistent. The website may be using the same color scheme as the
product dashboard, and hence the components get duplicated.
Backend Modules: If you have more than one backend, chances are that you
are duplicating the authentication, the logging, the middlewares, the utility
modules and many others depending upon your particular use-case.

Due to this, some parts of your website might look and feel different than the
other parts, worst-case it might feel they are built by different companies
altogether. And it's not just about how the UI looks, if you have duplicated
backend code, your team sometimes might end up debugging an edge-case over a
weekend that an engineer didn't think, while rebuilding the authentication
pipeline all over again.

To best avoid the above duplication, is to use the packages directory in your
monorepo root judiciously. That is if you followed the monorepo structure that
I advocated in the previous edition.

And if you are already doing that, it's better to keep the reusable modules kept
inside the packages directory - loosely coupled, highly parameterised and
customizable through environment variables and feature flags.

Consistent Business Logic

If there's one thing that you should absolutely avoid, then it has got to be
business logic duplication. Given enough time, codes change, bugs appear and get
fixed, engineers might come and go, but hardcore business logic seldom changes.

To give you an example, if you are building an accounting system, then your tax
calculation logic must never be repeated. If it does get repeated across your
backends and your frontends, then each update to the tax calculation logic,
debugging sessions and eventual hot-fixing, would need to be made across the
board and be forced to be compatible in each of the environments, causing
huge business consequences

I would like to recommend keeping a separate privileged module inside your
shared-modules, for such sensitive business logic and have a CODEOWNERS entry
such that unauthorised engineers (most likely the interns) can never make any
changes to the same.

An example CODEOWNERS entry might look something like this:

# .github/CODEOWNERS
# Guarding core business logic from unauthorized modifications

# Global fallback auditors
* @esence-io/platform-leads

# Strict guardrails for sensitive domain algorithms
/packages/domains/billing/tax-calculator.ts       @esence-io/finance-architects
/packages/domains/appointments/compliance.go     @esence-io/medical-directors

Documentation for Reusable Modules

This might be the only thing that separates an average organization from a
great organization that has some degree of foresight.

However, in an early-to-mid-stage startup, telling engineers to spend hours
writing long-form documentation on a separate Confluence or Notion workspace is
a fantasy. It creates out-of-date documentation platforms that nobody trusts,
adding to your organizational bloat.

The frugal, high-velocity alternative is Git-Adjacent Documentation:

Workspace READMEs: Every package inside your /packages/* directory
must contain a minimalist README.md explaining its API footprint, schema
rules, and runtime assumptions. If an engineer alters code logic, they update
the text in the exact same git commit string.
Strict Typing: Let your compiler act as your documentation
hub. By enforcing explicit input/output interface boundaries on shared
components, your IDE automatically tells the frontend engineer exactly what
parameters a component expects without them ever leaving their workspace
terminal window.
Better Code-Comments: Come-on, no one writes good comments.

If code isn't discoverable from inside the repo editor, it doesn't exist.
Keep it in git and the engineers will follow.

Trunk-Based Development: Unblocking the pipeline

What if every engineer works on the latest changes produced by every other team?
And what if every team starts taking ownership of the changes they make?

To answer both the questions in a strong Yes, your engineering team has to
follow the paradigm of "Trunk-Based Development".

Trunk-Based Development as opposed to module-versioning and importing foreign
modules from registries, means that a monorepo contains everything it needs and
every module it has, is on the latest version. And, cross-module dependencies
just become a question of either importing those modules or their DLLs or
binaries, completely bypassing the network-overhead of fetching latest modules.

There are no version numbers to increment, no private registries to maintain,
and no upstream breaking changes hidden behind a semver tag. And no wasteful
standup meetings discussing whether a change is breaking enough to bump up the
version entirely.

Once your company starts following trunk-based development:

If the Core Platform UI Team changes the button style or its parameters, it's
going to be the Core UI Team's responsibility to change it across the codebase.
Thereby, creating implicit ownership of all the changes that break integration
tests or that make other project's compilers scream.
The cost and complexity of infrastructure behind private module/package
registries instantly become zero and setting up the local environment for the
new joinee just becomes executing the build commands.
If a shared or an inter-team module breaks, no one has to get blocked for
getting fixes and updates.
All teams to some extent become software/module testers for all the other
teams by becoming a direct consumer with a zero-lag feedback loop.

One easy way to do it for TypeScript workspaces is by simply including workspace
dependencies like this:


  "dependencies": {
    "@packages/ui": "workspace:*"
  }

It isn't complicated, unless you start making it.

Compilation Lags and Caching Build Artifacts: With Nx

You pay money-tax to the government for earning, and pay time-tax to the
compiler for coding. Startups hire accountants for reducing tax paid to the
government, but seldom pay any attention to the tax paid to the compiler that
slowly leaks their pockets in terms of wasted productive hours of a developer
on a payroll.

You can read the full article on my blog - Engineering Insights at Esence.io

The Zero-Drift Ideal Monorepo Setup for Startups

Suraj Upadhyay — Sun, 14 Jun 2026 05:15:25 +0000

An Overhead-Free Monorepo Blueprint for High-Velocity Teams

The first design decision for any serious tech startup is to decide how their
codebase is structured, and building a monorepo setup often proves to be
crucial for avoiding cross-project dependency maintenance that can stretch
a small-to-mid sized engineering team which most startups cannot afford in
pre-venture or revenue stages.

What does an "ideal" monorepo look like?

While there are multiple ways a developer or a company can structure their
monorepos and it's true that there isn't an ideal setup that fits all case
scenarios, there are universal architectural truths that separate a clean
engineering workspace from a chaotic one

There are some salient features that every staff engineer or software
architect should aim to achieve with their monorepos:

Reproducible environment
Domain driven development
Module and library re-use
Trunk-based development
Central build cache registry
Simpler deployment pipelines
Package security, visibility and role-based code access

Most successful monorepos satisfy most or all of the above requirements.

I have worked with a couple of startups and have seen them all struggling with
getting most of the above requirements right.
Even established companies with
100s of engineers, sometimes have to spend hundreds of thousands of dollars,
if not millions, on platform engineers just to manage their codebase and build
pipelines.

Now, Let's go through each one of the "ideal monorepo" requirements and create
a best in class workspace for the engineering team.

Creating a Reproducible Environment

If you are a founder or someone from the tech leadership, there's a possiblity
that you hear this phrase a couple of times in a week - "it works on my machine,
I think something is wrong with the deployment". And most of the times, the
deployment turns out be just fine and it's the developer's local environment
configuration that's been acting up.

Also, there's a huge possiblity that every new engineer you onboard takes at
least 3 days to settle in and get comfortable with the codebase and all the
tools required to setup a normal working local environment.

What I have just described above is a classical design flaw from the early days
of a codebase, whether a monorepo or a polyrepo.

The medicinal anti-dote to this exact most common problem in tech companies is using
sandboxing tools that isolate the development environment and levels down the
playing field for all the engineers.

We are going to take a look at one of these tools today, that can easify your
life managing a tech team or running a tech company.

Devbox - The ideal sandbox for your dev environment

Devbox is an open-source, Nix-based package
manager that creates isolated, reproducible development environments without the
resource overhead of local Docker containers. And it is just the right tool to achieve
environment isolation that I have personally used in many of my projects.

It's not as heavy or expensive as managing docker configurations and forcing
developers to write code in docker native IDEs.

Let's start with the first steps of our desired setup:

# Install devbox
curl -fsSL https://get.jetify.com/devbox | bash

# Create directory for your codebase
mkdir monorepo
cd monorepo

# Initialise the monorepo with devbox
devbox init

Now, let's take a step back and ponder over our requirements from this virtual
environment. Most of the modern mid-level complexity full stack projects need
at least these pieces of tools to work correctly:

Essential Core Utilities:

Git (Version Control)

Frontend Engineering Layers:

Node.js (V8 Application Runtimes)
Bun (High-Performance Local Testing & Package Management)

Systems & Data Processing Services:

Go (Highly Scalable Backend Web Servers)
Python (Machine Learning Infrastructure & Automation Pipelines)
CMake/Make (Build tool for C/C++ used for high performance)

The list of the above tools is strictly my own choice and you can chose to go
with your own vibe of toolsets, that you want to be written on the stone for all
your team mates.

Let's install all of these and peg them against a version number to lock in the
tool of choice for everyone.

# Discover the versions of tools with
devbox search git --show-all # This gives a list of all available git versions

# Now add the desired version of the tool to your local environment
devbox add git@latest

devbox add node@latest
devbox add bun@latest

devbox add python@latest
devbox add go@latest

# Add any other tool(s) that your team needs

Now, the last step is to officially enter into the virtual environment that we have
created.

# Enter into the devbox environment
monorepo $ devbox shell

# Just when you execute the above command, your terminal prompt becomes this
(devbox) monorepo $

Now, whenever the new intern asks how he should pull the project and start the
contributing you just tell him to:

git clone <your-repository-location>
cd <your-repository>

# And...
devbox shell

# 🤯, he is all setup!!
# Now the only thing left is to execute the install scripts
# and actually run the projects.

And it just took him 2 minutes to start with the project without the weird
environment issues and it didn't matter if he is on Macbook or Linux or
Windows.

Go Task - A central registry for all commands in your project

Go Task is an open source utility that can map simple
words with complex commands, so that the junior devs never have to ping you in
the middle of the night just to figure out the command that they wrote had a
typo in it.

You can read the full article on my blog - Engineering Insights at Esence.io