You shipped multi-tenancy with a tenant_id column six months ago. Now your biggest customer wants isolated data, your compliance team needs audit logs, and the new reseller deal requires nested organizations three levels deep.

What is Stratum? That is the problem Stratum solves.

An open-source multi-tenancy library for Node.js and TypeScript. Hierarchical tenants, config inheritance, permission delegation, three database isolation strategies, and GDPR compliance, from day one.

The problem Stratum solves

Every B2B SaaS team starts the same way: add a tenant_id column to every table. It works, until your product grows.

Day 1

tenant_id on every table, manual WHERE clauses. Simple. Works fine.

Month 6

Enterprise customer needs custom configuration. You hand-roll config tables with no inheritance. Each customer is a special case.

Month 12

Compliance audit. You scramble to add audit logging, data export, and purge capabilities. Retroactively.

Later

Large customer demands data isolation. Painful migration from shared tables to schema-per-tenant. Engineering time for each piece.

The cost comes later. As the product grows, your team builds a weaker version of Stratum and spends engineering time on each piece. Stratum gives you all of this from day one.

How Stratum works

Tenant hierarchy

Tenants form a tree. A root organization can have resellers, who have clients, who have teams. Config and permissions flow down the tree automatically.

  1. d0AcmeSecroot
  2. d1NorthStar MSPreseller
  3. d2client-alpha
  4. d2client-beta
  5. d1Apex Partners
  6. d2client-gamma

Config inheritance

Set a value on the root tenant and every child inherits it automatically. Lock a key so children can't override it. Override it at any level when needed.

root: max_users = 1000← set once
├─ child-a: inherits 1000← automatic
└─ child-b: max_users = 500← override
root: region = "eu" (locked)← children cannot change

Three isolation strategies

Choose per tenant. Mix strategies in a single deployment. Upgrade a tenant's isolation level without migrating data.

Shared RLSSame tables, PostgreSQL Row-Level Security. Lowest cost, highest density.
SchemaSeparate schema per tenant. Stronger isolation, still one database.
DatabaseDedicated PostgreSQL instance. Maximum isolation for compliance.

Why we built Stratum

We've seen multi-tenancy pain firsthand, at security platforms (MSSP/MSP) where nested tenant hierarchies are the norm, and at B2B SaaS companies where enterprise customers demand isolation, custom config, and compliance.

Every team we worked with had the same story: they started with tenant_id, then built config tables, then added audit logs, then scrambled for isolation, each time reinventing what should be infrastructure.

The Node.js and TypeScript ecosystem has no dominant multi-tenancy library. The .NET world has ABP.IO. Ruby has Apartment. Node.js developers roll their own every time. Stratum changes that.

Stratum vs alternatives

CapabilityStratumtenant_id columnWorkOS / FronteggCustom built
Tenant hierarchyYesNoNoBuild it yourself
Config inheritanceBuilt-inNoNoBuild it yourself
Isolation strategies3 (RLS, schema, DB)Manual RLSNoBuild it yourself
GDPR complianceExport + purgeNoPartialBuild it yourself
Audit loggingBuilt-inNoAuth events onlyBuild it yourself
Setupnpm install and initialize()A column and a filter on every queryA vendor account and an SDK integrationEngineering time for each piece
Open sourceMITN/AProprietaryYours

Get started in 5 lines

quickstart.ts
import { Pool } from "pg";
import { Stratum } from "@stratum-hq/lib";

const stratum = new Stratum({ pool: new Pool(), autoMigrate: true });
await stratum.initialize();

// Create a tenant and set config
const org = await stratum.createOrganization({ name: "Acme Corp", slug: "acme" });
await stratum.setConfig(org.id, "max_users", { value: 100 });
// That's it. Multi-tenancy with config inheritance, ready to go.

Ready to stop reinventing multi-tenancy?

Get StartedGitHub