Stratum vs the alternatives

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.

The cost comes later. As the product grows, a hand-rolled solution tends to accumulate: 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 build that isolation yourself. Stratum sets the isolation strategy per tenant when you create the tenant, so that customer can start on a database of its own.

Stratum puts that structure in place from the start. Not because you need every piece immediately, but because the architecture is already in place when you do.

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.

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.

Clerk Organizations and Auth0 Organizations live at the authentication and membership layer. They model who belongs to which org, hand you a polished invitation and member-management UI, let each organization bring its own SSO connection, and put an org_id in the session token. For the login and org-switching experience, they are hard to beat.

What they deliberately don't touch is the layer below the token. They don't isolate a tenant's rows in your database, inherit config down through nested tenants, enforce row-level security, audit the data mutations your app performs, or purge a tenant's data for a GDPR request. That's not a gap in the products. It's simply not the layer they operate at.

Stratum takes the org_id those systems already resolve and builds the tenant data layer beneath it: the isolation strategy, the config tree, permission delegation, and the compliance workflows. The two compose cleanly: Clerk decides who is in the org, Stratum decides what that org's data can do and where it lives.

Nile virtualizes tenants at the database itself. You build on Nile's hosted Postgres and get per-tenant isolation baked into the platform. If you're greenfield and comfortable putting your data on a startup database vendor, it's an elegant story: tenancy is a property of the database, not something you assemble in application code.

Stratum takes the opposite stance on where tenancy lives. It's an MIT-licensed library that runs over your existing PostgreSQL: RDS, Supabase, Neon, or self-hosted. So there's no database to migrate to and no vendor to depend on. On top of that Postgres it adds the application-layer tenancy model Nile doesn't aim to cover: nested tenant hierarchy, config inheritance with lockable keys, permission delegation, and GDPR export/purge workflows.

So the choice is less feature-by-feature and more about ownership. Nile asks you to adopt a database; Stratum asks you to keep yours and drop in a layer. If nested tenancy, config inheritance, or compliance operations matter to you, those are Stratum's territory regardless of which Postgres you run.

Oso and Permit.io are built to answer one question extremely well: given a subject, an action, and a resource, is it allowed? They give you a policy language, ReBAC/ABAC evaluation, and a place to centralize app-wide authorization logic. If your access rules are rich and cross-cutting, a dedicated policy engine is the right tool.

What they don't provide is the tenancy substrate: the tenant data model, the isolation strategies (RLS, schema, database), config inheritance down a tenant tree, tenant lifecycle operations like onboarding, archive, and purge, or an audit trail of tenant data mutations. A policy engine decides whether an action is allowed; it doesn't store, isolate, or manage the tenants themselves.

There is one honest overlap. Stratum's permission delegation and ABAC cover permissionswithin a tenant hierarchy: delegation modes with cascade revocation, and ABAC policies that inherit down the tree. That's narrower and more opinionated than a general policy engine, and for tenancy-scoped access it's usually enough on its own.