Faiz Ahmed Farooqui About

How to Architect Multi-Tenant SaaS Backends in 2025 (PostgreSQL + Node.js)

2 min read scaling-javascript-nodejs

#nodejs#postgresql#saas#multitenancy#software-architecture#tech-leadership#devtools#javascript#express

In the world of SaaS, designing for scale starts with multi-tenancy done right.

Why Multi-Tenant Architecture Matters

SaaS is all about shared infrastructure. Whether you’re serving 5 customers or 5,000, you need to:

  • Isolate customer data securely

  • Scale efficiently without ballooning costs

  • Keep deployments sane

Multi-tenancy lets you do all of that - when designed correctly.

Multi-Tenancy Models: Which One?

ModelDescriptionProsCons
Shared DB, Shared TablesAll tenants share the same schemaEasiest to manageRisk of accidental leakage, hard to scale
Shared DB, Separate SchemasOne DB, one schema per tenantGood balance of isolation and performanceSlightly more infra overhead
Separate DB per TenantOne DB per tenantMax isolation and flexibilityComplex infra, costly at scale

We’ll focus on schema-based multi-tenancy, it’s a sweet spot for SaaS products targeting SMBs to mid-market.

PostgreSQL Multi-Tenancy Strategy

Schema-Per-Tenant

Each customer gets their own schema:

public.users        → shared
tenant_abc.orders   → tenant-specific
tenant_xyz.orders   → tenant-specific

Security with RLS

Use Row-Level Security (RLS) in public/shared tables:

CREATE POLICY tenant_isolation
  ON public.users
  USING (tenant_id = current_setting('app.current_tenant'));

And set this in every DB connection via middleware:

SET app.current_tenant = 'tenant_abc';

Connection Pooling Tips —

  • Use pgbouncer in transaction pooling mode

  • For AWS, consider RDS Proxy with connection pinning (for long sessions)

Backend Design with Node.js

Middleware-Based Tenant Resolution

app.use((req, res, next) => {
  const subdomain = req.hostname.split('.')[0];
  req.tenantId = resolveTenant(subdomain); // resolve to `tenant_abc`
  next();
});

Request-Scoped DB Access

Using a dbForTenant(tenantId) helper to inject the right connection:

const db = dbForTenant(req.tenantId);
const orders = await db('orders').select('*');

Or with ORMs like Prisma or MikroORM:

  • Generate client instances dynamically

  • Use schema switch or connection pool keying

Infra & Operational Considerations

  • Migrations per schema using tools like node-pg-migrate

  • Backup strategies to snapshot all schemas

  • Rate limiting by tenant key

  • Audit logging per tenant using middleware hooks

End-to-End Flow

flowchart TD
  A[Incoming Request: customer.abc.app.com] --> B[Middleware Resolves Tenant ID]
  B --> C[Set DB schema search_path to tenant_abc]
  C --> D[Run Queries against tenant_abc.orders]
  D --> E[Send Response Back]

Real-World Lessons

  • Avoid hardcoding tenant logic — use context-injected data

  • Monitor schema bloat over time

  • Start with fewer shared tables — easier to migrate than split later

  • Automate tenant provisioning (create schema + seed data)

Conclusion

Multi-tenancy isn’t a feature, it’s a foundation.

With PostgreSQL schemas and clean Node.js abstractions, you can scale from one tenant to thousands without rewriting your stack.

Got questions about your SaaS backend?

Drop a comment or DM me.

Always happy to help troubleshoot, scale, or design multi-tenant platforms with you.

Related posts