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.

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.

Month 18

Large customer demands data isolation. Painful migration from shared tables to schema-per-tenant. Three months of engineering work.

By month 18, your team has built a worse version of Stratum and spent 3+ months doing it. 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.

AcmeSec                    ← root
├── NorthStar MSP             ← reseller
│   ├── client-alpha
│   └── client-beta
└── Apex Partners
    └── client-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 RLS

Same tables, PostgreSQL Row-Level Security. Lowest cost, highest density.

Schema

Separate schema per tenant. Stronger isolation, still one database.

Database

Dedicated 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

	Stratum	tenant_id column	WorkOS / Frontegg	Custom built
Tenant hierarchy	Yes (20 levels)	No	No	Build it yourself
Config inheritance	Built-in	No	No	Build it yourself
Isolation strategies	3 (RLS, schema, DB)	Manual RLS	No	Build it yourself
GDPR compliance	Export + purge	No	Partial	Build it yourself
Audit logging	Built-in	No	Auth events only	Build it yourself
Time to implement	60 seconds	1 day	1 week	3+ months
Open source	MIT	N/A	Proprietary	Yours

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.