Roadmap
Work lives in issues, grouped by milestone. A milestone outlives the release named after it — issues keep being filed against one long after the version ships — so the release marker and the milestone progress on each card are two different facts. This page is the context around them, and how to contribute covers the standard a pull request is held to.
Breadth
Tenant-scoped cache keys and per-tenant eviction, schema-per-tenant routing, and the connection strategy seam everything else now hangs off. Caching came first because a cache hit never reaches the database, so no policy can help it.
milestone · 10 of 17 closed
The one that mattered
Database-per-tenant routing, per-tenant migrations, and the configuration-driven strategy switch. Together they fixed the shape of the isolation abstraction, which is why 1.0 comes after this and not before.
milestone · 3 of 4 closed
Running it in production
Onboarding a tenant in one call, provisioning hooks, the registry over HTTP, a start-up scan that names the tables Postgres is not actually protecting, and per-tenant metrics that cannot run up an unbounded bill.
milestone · 1 of 7 closed
Where isolation can still be defeated
Three of these are inherent rather than unbuilt — they are properties of Postgres and of connection pooling, and no amount of library code removes them. They are listed because you need to know them before you deploy, not after.
- A superuser bypasses every policy — and so does the table owner, unless the table is declared
FORCE ROW LEVEL SECURITY. Applications very often connect as the owner, which is why the generated policy always emitsFORCEand why the start-up checker reports the connection that is a superuser. - PgBouncer in transaction or statement pooling mode — the tenant is a session-level setting, and those are unsupported there, so it can leak between clients. If the application looks correct and the leak looks random, this is the first thing to check.
- Unwrapping a pooled connection to a raw
PgConnection— from that point on you are outside the wiring, and nothing sets or clears the tenant for you.
Listed here because a roadmap that hides its sharp edges is marketing, not a roadmap.
The whole surface
Multi-tenancy is not one feature. Here is every concern it involves, and exactly where we are on each — including the rows that are still empty.
| Concern | Shipped in 0.4.0 | Planned |
|---|---|---|
| Tenant resolution |
| — |
| Context & propagation |
| |
| Isolation strategies |
| |
| Authorisation |
| — |
| Schema & policies |
| — |
| Tenant registry |
| |
| Migrations |
| |
| Caching |
| — |
| Observability |
| |
| Testing |
| |
| Dashboard | — |
Every planned item is an open issue. 15 of them are unclaimed.
What is not on this list
TenantLayer is open core. Everything above is the free core, and the rule that decides what belongs in it is published:
Free is correctness. Paid is operations, compliance and scale. Would a two-person startup need it before they have customers? Free. Would a team closing their first large enterprise deal need it? Paid.
The free core is never crippled to sell the paid one. If something is needed to build tenancy correctly and it is not here, that is an omission worth an issue — and the rule above is what the argument gets held up against.
Deliberately out of scope entirely: cross-region replication, active-active and failover orchestration. Those belong to the database platform. TenantLayer stays region-aware and never becomes a replication control plane.