Stratum vs the alternatives
Four ways to handle multi-tenancy in Node.js. An honest look at each.
Stratum vs rolling your own (tenant_id)
The default choice. Add a column, filter every query, ship it. Works fine early on. The problem is what happens next.
On day one, rolling your own looks correct. A tenant_id column is simple,
understood by every developer on your team, and requires no dependencies. You're not
over-engineering. Good instinct.
The issue isn't day one. It's month 18.
By month 18, your hand-rolled solution has accumulated: a config table with no inheritance model, audit logging added retroactively and missing half the mutation points, no isolation options beyond the shared schema you started with, and GDPR compliance that lives in a Notion doc but not in code. When an enterprise customer demands a separate database for their data, you're looking at a full-quarter migration.
Stratum gives you month-18 features on day one. Not because you need them all immediately — but because the architecture is already in place when you do.
| Capability | Rolling your own | Stratum |
|---|---|---|
| Setup time | 1–2 days | 5 minutes |
| Tenant hierarchy | Build it yourself (weeks) | Built-in (ltree, 20 levels) |
| Config inheritance | Build it yourself | Built-in, root-to-leaf |
| Isolation strategies | Manual RLS only | RLS, schema, database — per tenant |
| Audit logging | Bolt on later | Every mutation, actor-attributed |
| GDPR (Art. 17 + 20) | Build it yourself | Export + purge, built-in |
| Field encryption | Build it yourself | AES-256-GCM, transparent |
| Month-18 cost | 3+ months engineering | Already done |
Stratum vs WorkOS / Frontegg
WorkOS and Frontegg are excellent products. They solve a real problem. Just not the same problem Stratum solves.
WorkOS and Frontegg operate at the identity and authentication layer. They handle SSO, SCIM provisioning, audit logs for auth events, and organization management in the context of who can log in. They do this extremely well.
Stratum operates at the data tenancy layer. It handles how your database stores, isolates, and manages data across tenants. These are different problems at different levels of your stack, and the right answer for most teams is both.
Use WorkOS or Frontegg to manage authentication and user provisioning. Use Stratum to manage data isolation, config inheritance, and compliance operations on the PostgreSQL side. They complement each other — they don't compete.
| Capability | WorkOS / Frontegg | Stratum |
|---|---|---|
| SSO / SAML / SCIM | Yes — core product | Not in scope |
| Auth event audit log | Yes | Not in scope |
| Data isolation strategies | No | RLS, schema, database |
| Tenant hierarchy / tree | Flat organizations only | 20-level tree, ltree-backed |
| Config inheritance | No | Root-to-leaf, lockable keys |
| GDPR data operations | Partial (auth data only) | Full export + hard purge |
| Data mutation audit log | No | Every mutation, actor-attributed |
| Pricing model | Proprietary SaaS | Open source, MIT |
The right stack: WorkOS or Frontegg for authentication and user management. Stratum for data tenancy and compliance. Both in the same application, each doing what it's built for.
Stratum vs ABP Framework
ABP is the gold standard for multi-tenancy in the .NET ecosystem. Stratum is the equivalent for Node.js — the library that should have existed years ago.
ABP Framework (formerly ABP.IO) is a mature, opinionated application framework for .NET that includes multi-tenancy as a first-class concern. Teams building C# applications have had this foundation for years. It's well-documented, battle-tested, and handles the full lifecycle: tenant resolution, data isolation, config, and more.
Node.js and TypeScript developers have had no equivalent. When we looked at what ABP provides and compared it to the npm ecosystem, the gap was stark. We built Stratum to close it.
Stratum is not a port of ABP — the Node.js and TypeScript ecosystem has different conventions and constraints. But the motivation is the same: give developers in this ecosystem a stable, production-ready multi-tenancy foundation so they stop reinventing it.
| Capability | ABP Framework (.NET) | Stratum (Node.js) |
|---|---|---|
| Runtime | .NET / C# | Node.js / TypeScript |
| Tenant resolution | Yes (header, subdomain, JWT) | Yes (SDK middleware) |
| Data isolation | Schema + database strategies | RLS, schema, database |
| Tenant hierarchy | Parent-child (2 levels typical) | Arbitrary depth, ltree-backed |
| Config inheritance | Settings system | Root-to-leaf, lockable keys |
| GDPR tooling | Partial via modules | Export + purge, built-in |
| Open source | Partial (community edition) | Fully open source, MIT |
| npm / TypeScript native | No | Yes — built for the ecosystem |
The short version
The DIY approach works until it doesn't. Stratum gives you the infrastructure you'll need at month 18, from day one.
Different layer of the stack. Use them for auth. Use Stratum for data. They complement each other.
ABP is great for .NET. Stratum fills the same role for Node.js. If you're writing TypeScript, there's no equivalent — until now.
See how Stratum works with your stack
Stratum integrates with the ORM and database you already use. No migration required.
Start with Stratum today
npm install @stratum-hq/lib pg