Nile puts virtual tenants inside Postgres instead of beside it

The tenant is the unit, and it gets its own database

Nile describes itself as a Postgres platform that decouples storage from compute, virtualizes tenants, and supports vertical and horizontal scaling globally to ship B2B applications fast while being safe with limitless scale.

The opening line of the README is a statement about B2B software rather than about databases. All B2B applications are multi-tenant. A tenant or customer is primarily a company, an organization, or a workspace in your product that contains a group of users. A B2B application provides services to multiple tenants. Tenant is the basic building block of all B2B applications.

That framing is the product decision. A conventional multi-tenant Postgres application puts every customer's rows in shared tables and separates them with a tenant_id column, with row level security policies enforcing the boundary. The alternative, which is what a lot of B2B customers actually ask for, is a database per customer, which is operationally expensive in a serverless environment where every database is a separate thing to provision, bill and back up.

Nile's answer is in the feature list: unlimited Postgres databases and unlimited virtual tenant databases, with secure isolation for customer data and vector embeddings. So each tenant gets what looks like its own database, virtualized inside the platform, and the platform handles the isolation.

The repository topics confirm the shape: multitenant, postgresql, saas, serverless, multiregion, authentication and vector. The name of the platform appears in the package description as tenant aware, serverless, globally distributed postgres.

Four components, and two of them are not the database

The README lists four components, and the split matters for what you actually need.

The first is Postgres re-engineered for multi-tenant apps. The second is tenant virtualization, which has its own documentation section as a distinct component. The third is Nile Auth, described as drop-in B2B auth with customer data in your Nile Postgres. The fourth is an AI toolkit and vector database.

Auth and AI are the two that go beyond being a database, and they are worth looking at separately, because the value proposition of the platform is the combination rather than any one piece.

Nile Auth storing customer data in the same Postgres as the application is the interesting decision. In a typical B2B stack, authentication means an identity provider holding users, and the application database holding a copy of them, and the two have to be kept in step. If the identity records live in the same tenant-aware Postgres the application already queries, that synchronisation problem largely disappears, and the tenant model applies to users as well as to application data.

The AI toolkit and vector database are described with two concrete claims in the feature list: customer-specific vector embeddings at 10x lower cost, and autoscale to millions of tenants and billions of vector embeddings. The cost claim comes from the isolation model, since embeddings for one customer are isolated the same way the rest of that customer's data is, rather than sharing a flat vector index across everyone.

The vector side is also the one that explains the multiregion and serverless topics, because embeddings are the data type that grows fastest in a modern B2B product, and the per-tenant isolation is what makes it possible to scale that without one giant index becoming a bottleneck.

Serverless or provisioned compute, per tenant

The feature list says tenants can be placed on serverless or provisioned compute, globally, and that there is tenant-level branching, backups, schema migration and insights.

Placing tenants on serverless or provisioned compute is the part that separates this from a database with a tenant column. In a serverless Postgres platform, compute scales to zero when nobody is using the database, which is what makes a per-tenant database affordable. The ability to choose between serverless and provisioned compute per tenant then covers the case where one large customer needs guaranteed resources and the long tail of small customers should not be paying for idle capacity.

The tenant-level operations are the other half. Branching at the tenant level means a schema change can be tested against a copy of one customer's data without touching production, which is the operation a multi-tenant application performs constantly. Backups and schema migration at that level are what you would need to run a hundred customer databases without a hundred separate operational processes, and insights is the observability surface for the same purpose.

Decoupling storage from compute is the underlying architectural choice that makes all of this work. Storage is shared and durable, compute is elastic and possibly per-tenant, and a tenant's data survives its compute being switched off.

It is worth being clear about the trade this implies. Virtualized tenant databases mean you give up some of what a real separate Postgres instance gives you, in exchange for the operational simplicity and the cost profile. The README does not spell out the isolation mechanism in detail, which is exactly what the tenant virtualization documentation is for.

Public preview, a hosted console and a Docker image

Nile is in public preview, and the README says so in two places, including a standalone line in the features section and again in the documentation section. That is the first fact to hold on to, and it is the one that should shape any plan to depend on it.

The getting started options are a hosted path and a local one. You can sign up to Nile at console.thenile.dev, or try it locally using the project's Docker image, with a dedicated page for the Postgres Docker setup. The README also points at a short read, Nile in 3 minutes, for a three minute overview.

The repository itself is interesting to look at for a different reason than the product. It is not the database source. The primary language is listed as MDX, the top level has www/ which is the documentation site, and examples/ holds the runnable examples, with a pnpm workspace, turbo.json and a packageManager field pinning pnpm 10.24.0.

The workspace list in the root package.json is a catalogue of the stacks the platform is meant to work with. It includes examples/quickstart/nextjs, examples/quickstart/java/fe, examples/quickstart/drizzle/fe and examples/quickstart/prisma/fe, examples/serverless/lambda-drizzle/fe, examples/integrations/stripe_subscription, examples/user_management/email_login/NextJS, examples/user_management/sso_login_okta/NextJS, examples/user_management/social_login_google/NextJS and examples/user_management/NextAuth. Alongside them, the examples/ directory also lists ai/ with ai_pdf and code_assist, plus migrations/, integrations/, quickstart/, serverless/, use_cases/ and user_management/.

So the examples cover the ORM question (Drizzle and Prisma), the runtime question (Next.js, Java, Lambda), the payment question (Stripe subscriptions) and the identity question (email login, Okta SSO, Google social login, NextAuth). That is a good map of what a B2B product needs on day one.

The gaps to check before you build on it

The first is the preview status, and it is not a formality. A public preview means the behaviour, the pricing and the API surface can change, and the feature list itself uses language like safe with limitless scale for something that has not yet been released generally. The README does not describe a versioning or compatibility promise, and there are no GitHub releases to pin to, so a project that depends on Nile is depending on a moving target with a documentation site as its only contract.

The second is the isolation model, and this is the one to read most carefully. The product claims secure isolation for customer data and vector embeddings, but the README does not say how. Whether tenants share a physical Postgres instance with logical separation, or get separate instances, or something in between, determines what you can promise your own customers, and that promise is often contractual. A multi-tenant platform whose isolation story is in a separate documentation page is asking you to read the documentation, which is fair, but the README is not where the answer is.

The third is the cost claims. Customer-specific vector embeddings at 10x lower cost and autoscale to millions of tenants and billions of vector embeddings are both strong statements without published benchmarks. In a database product, cost per tenant is a number you build your business model on, so it is worth asking for the derivation rather than accepting the figure.

The fourth is the operational surface. Nile is a platform, not a library. Adopting it means your application talks to a hosted service, or to a Docker image you run, and it means a dependency on a company in public preview rather than on a Postgres version you can install. The counterargument is fair, since running one database instance per customer is exactly the cost the platform is arguing against, but it is a real trade.

The fifth is the licensing inconsistency in the repository itself. The README and the repository listing say Apache-2.0, and LICENSE.txt is at the top level, while the root package.json declares license as MIT. The package.json also names the repository as git+https://github.com/TheNileDev/niledatabase.git while the repository you are reading is niledatabase/niledatabase. None of that says much about the product, but it is the kind of detail worth raising with the team before you build a business on the platform.

Editorial conclusion

Nile suits a team building a B2B product where every customer is a company with its own data, and who would rather have one Postgres cluster with virtual tenant databases than run a database per customer. It is the wrong tool for a single-tenant application, and the wrong tool if you need a stable, supported production service today, because the project states it is in public preview. Before adopting it, read the tenant virtualization documentation rather than assuming the isolation model matches Postgres row level security, because the whole product rests on that boundary. Verify first that the examples cover your stack, since the repository ships examples for Next.js, Java, Drizzle, Prisma, Lambda, Stripe and several auth providers.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. niledatabase/niledatabase on GitHub
4. Project website
5. README