Nile co-founder here :)
Nice surprise to see our launch here. Happy to answer any questions...
Nice surprise to see our launch here. Happy to answer any questions...
Modern SaaS applications are multi-tenant. We’re the first database that virtualizes tenants into the database. A tenant is primarily a company, an organization, or a workspace in your product that contains a group of users. This enables seamless tenant isolation, per-tenant backups, and placement on multi-tenant or dedicated infrastructure, anywhere on the planet. You can do all this with the experience of a single Postgres! You don’t have to manage multiple databases, build complex permissions for isolation, or write buggy scripts to read specific tenant data from backups. On top of the tenant model, we provide opt-in user management capabilities, customer-specific vector embeddings, and instant tenant admin dashboards.
You manage schemas like how you manage with standard Postgres. Your favorite tooling should work. When you make the schema change, Nile pushes the schema to all the tenants. For the user, it is like interfacing with a single Postgres instance.
We have built a Rust based layer internally to manage tenants, route them, shard them if needed and have multiple tenants talk to each other. Happy to chat more. My email is ram@thenile.dev
This is true in a sense “most modern SaaS apps have at least two unrelated users or user groups” (forgive me please if I’m wrong here, but that’s how I loosely understand “multi-tenant”), but it’s not exactly clear why this is important.
I strongly suspect that the majority of modern SaaSes don’t do any database-level tenant isolation or per-tenant backups. The smaller the company the less it’s likely. Row-level security is a very rare sight to behold, even in regulated areas (certifications like HIPAA compliance don’t really require this). The best they do if they’re really global (I’m sure most are only global in “we accept users from anywhere”, but not so much under the hood - even though cloudy sales pitches love to paint a different picture, most SaaSes I’ve seen were one or two-region deployments) is try to move/shard data closer to the the user’s region.
I think one concrete example (as simple as possible) would help a lot.
I'm not sure that I would generalize that to all modern SaaS applications though.
1. GitHub helps a group of developers manage and deploy their code. Each Github organization is a tenant, and the developers within those organizations are users. 2. Salesforce or Hubspot helps sales reps manage their leads. Each company is a tenant, and the users are the sales reps. 3. Ring is a home security company that provides alarm services to different households. Each household is a tenant, and people living in a house using their service are users. 4. Toast is a platform to help build software for restaurants. The restaurants are tenants, and the employees of the restaurants are the users.
Nope, Github users exist outside of organizations in a global namespace, and can be invited to be members of multiple organizations.
Also, how is Nile different from creating a database (or several databases) for each tenant within a single Postgres cluster?
Nile is different from DB per tenant in a single PG cluster in that it is much lower overhead per tenant. Since we offer a service, it will translate to lower cost.
The DB-per-tenant gets painful after the first few 100 tenants, but some SaaS have thousands of tenants, each with very low activity. Our model makes inactive tenants nearly free.
In addition, we also provide the "unified view", which lets you query all your tenants as if they were in the same DB. So you can connect as an admin and "select * from my_table" will give you the results for all tenants. Can be pretty handy.
What are you thinking will happen when a SaaS grows like Salesforce, with a very large number of tenants, where some of the tenants have very large databases? What will Nile do when the database just can't fit in a single Postgres cluster?
Edit: Never mind, I see from your web site that moving tenants between databases is one of the main things you try to address.
Tenants are your customers. It is normal for SaaS to have either a schema per tenant or one schema and tenant_id column in most tables. Nile provides you with both experiences at the same time.
If they travel a lot, you may want the data in one location (although it still depends, moving data is often faster than flying to a different region).
Tenant placement is especially great if their location has data residency requirements. We discovered that companies with many EU customers need this.
For most of my apps, I have very little idea on their region aside from their login IP origin, and we get a high level of multi-region travels (like conference organizers). I'd encourage you to transform the notion of a tenant transfers from a 'major decision' to 'assume users will/should switch to closest tenant login'. It looks like your platform already allows this move-tenant-on-login approach, but I'd love to see more docs and more tests around that use-case.
update tenants set deployment_mode = 'shared' where name = 'customer 2';
The architecture includes proxy layer that handles routing and maintains the connections, so we believe broken connections are avoidable.
With Flask it is fairly straightforward - you add the tenant configuration to the DB connection when you pick it up to serve a request. The Java and NodeJS examples do something similar if you need to see the idea.