I've been interested to see what Nile will be since the Twitter pre-announcement, and: uff.
The tenant capabilities are nice to have, but even when building a tenant-focused SaaS not really a big draw. The examples shown even come down to "you can achieve 80% of this by just adding a tenant column everywhere". When comparing this to e.g. Supabase, their autogenerated REST/GraphQL APIs solve a lot more significant pain points, especially when starting out.
Sorry to hear that. We understand each one will have a different set of problems. From our experience and talking to others, it is usually not as simple as adding a tenant_id column. You typically care about security from day one and want to be really careful how you isolate customers. You would also want to add user and organization management easily to the product. We have made these steps really easy without having to spend time writing complex permission logic and potentially buggy code. We also are able to provide query insights by tenant since the database understands tenant boundaries. There are also other things that I have mentioned in the blog. Having said that, if our users want autogenerated APIs, we would be more than happy to invest in it. We did have plans for it but in our conversations most did not bring it up. Hopefully, we can convert you to love Nile as we grow.
> You would also want to add user and organization management easily to the product.
That's usually something that I'd outsource as much as possible to Auth0 (yikes, considering the last days), as building out the UIs and state handling for all user auth and management flows is a huge chore. I think recently Clerk has set a new standard on how easy that can be.
I'd be surprised if a database product could compete in a meaningful way in that area.
I'm looking forward to see what Nile evolves to! (IIRC Supabase also didn't look that enticing when it first appeared on the map). In general I'm really happy to see databases as such an active space of innovation again.
"Grow for years" only really works if your SaaS also exists in years. I can't imagine deciding to run a production DB with a custom RLS thing going on without being able to directly port that off-provider in a worst case scenario. Supabase sort of gets around this by being open source, but even then depending on their custom setup gives me a little anxiety. Not sure about other managed/"serverless" Postgres.
Nile CEO here. Nile will promise to make the experience of moving out of Nile really easy. This is one our core product principles. We want users to stay for the value we provide.
Nile user permissions are optional. You can decide to use any third-party provider for it. We are in the design phase for permissions at this point. We would love to get your feedback to understand more about your concerns
https://github.com/orgs/niledatabase/discussions/159
This is why we don’t run a fork of Postgres, and we lean heavily into extensions rather than customizations. As the docs mention: this forces us compete on experience.
(Speaking here to your point about supabase, not to detract from Nile, which looks very cool)
I use Supabase at work for this reason, just not sure I'm _completely_ prepared to pick up and move to a non-Supabase PG if I really had to, which is a little unsettling for long term reliability. This is probably a me problem, you guys are doing great work on avoiding lock-in.
I wonder how this compares to e.g. Citus with some triggers and RLS on top.
As this does regional accesses of shared and modifiable data, does Nile implement or guarantee snapshot consistency for cross-shard queries? Citus doesn't have this yet, iirc.
From the docs, I assume Nile does something like the following:
- "smart partitioning" of tables on tenant_id when tenant_id is detected on table creation. These partitions are either region-local when the tenant is located in that region, or foreign tables. (Alternatively, non-local tenant data is replicated with e.g. logical replication/LR, or triggers)
- global tables are replicated across all regions, again presumably with LR
- RLS on the smart partitioned tables, which applies the tenant filter when nile.tenant_id is set.
Do you have any docs where I can read up on this in more detail?
All in all this looks like a real neat project. Congrats on launching.
Very cool. This is Sai, ex-Citus and currently PeerDB. You are promising many features incl. region aware tenant placement, tenant level metrics, easy tenant isolation etc. which would really help multi-tenant SaaS customers. Back during my days at Citus, we spent many cycles to a build a database for SaaS. We built some (not all) the features you mentioned and saw customers really finding value.
Congrats on the launch. I would love to try out Nile in the future!
Nile CEO here. Nile abstracts away compute machines and provides an experience where you can easily scale up or down based on the load you push.
Specifically, Nile lets you do the following
- Create a database and start querying it. Nile takes care of adding capacity to tenants as workload increases.
- Pay for what you use. You will only pay for what you use. We have plans for pricing where you can pay based on usage per tenant. This will ensure your business value is aligned with the cost of your database. For example, a customer on your free tier may not be an active user and you would not pay for them in Nile.
- We have built multitenancy into Postgres and a gateway layer that routes. This helps us to scale to zero with instant availability when you want to scale back up.
- You can create even a million tenants if you have that many customers.
- We have built connection pooling into Nile. This helps to provide limitless connections as you grow
I'm still trying to understand the scaling story better. When we say serverless it mentions automatically scaling when it detects some sense of resource pressure. If I have a "hot tenant-database", does that mean this shard will be scaled automatically without impact to existing queries? Or would there be some "blip". I suppose it's unavoidable in edge cases but curious about the regular ones as well.
It's an incredibly cool CX you have here with the automated query routing/tenancy story though, looking forward to what happens in this space.
I learned this probably later than I should have, but "serverless" now has two meanings.
The first meaning I was familiar with was the idea that there was no long-running process operating a service. This was like a lambda, executing upon a trigger and then stopping.
The second meaning I learned about more recently was the idea of "serverless" being an abstraction layer, where you don't think about what server the service is deployed on (specifically, you get to stop caring about the resources allocated to that server), even though it is deployed as a continuous, long-running process.
Serious follow-up question: So the difference between 'managed' and 'serverless' databases is that for the former I know some level of infrastructure (CPU, RAM, size, etc.) whereas for the latter it's completely hidden and priced in?
I was also only aware of your first definition of serverless.
The tenants concept is really cool and something I'm fighting with right now. I actually went single-tenant from day 1 (not exactly on purpose) and it's a been a pain to find a DB solution that will work well for me.
I absolutely love PlanetScale but having 1 database per client means paying for 1 plan per client. I'm B2B so I have way fewer "clients" but my load is incredibly spiky for each client (75% of the time they have near-0 usage, 20% of the time they have a tiny amount of usage, and the 5% they use a bunch). As it stands right now their heavy load never overlaps so I've been mulling over a move to an RDS cluster where I can run multiple databases on the same hardware.
I'm not super interested in migrating to Postgres (though I think my app would move relatively easily, I don't use anything super MySQL-specific, it's just what I know) but I'll be watching this project as it moves forward. I'd really like to not manage my own DB, it's not where I'm strong and I'd rather focus on other things.
Sorry to hear your problems. We would be a great fit for your use case. We are serverless and support spiky workloads. You can map your clients to tenants in Nile. Let us know if anything changes on your side in the future. I would love to connect.
Nile CEO here. I agree, and I am with you. I can vouch that this is not done with any malicious intent. We were not ready for HN yet but here we are. Our goal was to work with initial users to really polish the product before we open it up to everyone. We understand this would discourage some to not join and we hope to get them back once we are available for general availability.
After reading the landing page, I have no idea what I would use this for or what a tenant means. How do I manage my schema? How do I do migrations? Is this thing running all the time? What's the tech stack underneath?
Nile CEO here. Thanks for the feedback. Let me try to explain it a bit.
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
It is a Postgres, so schema and migrations work exactly as they would elsewhere.
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.
At first pass, I'm impressed with the multi region/tenant built-in support. I take it that changing a region is as changing the table row key. I wonder though about this strategy strictly place user's data as an entry into the data store... what if my users travel a lot between regions? Is the best strategy that upon user login to update their region in all their related tables?
Nile CEO here. Nile provides tenant virtualization. Each tenant has a group of users within them. Typically, you would choose one location for a tenant. This will be based on your customer location. This would mostly stay the same. The users in a company could travel, but the choice of region is usually decided by where the company is located. Yes, you would be able to change the location of a tenant and the data will be moved to a new region but this usually happens if there is a major decision about location in a company.
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.
Cool product if it works as promised with one caveat - I have saas app on django. I would happily migrate it from current setup to something that promises Tenant separation out of the box. But I'm not dropping the framework anytime soon. How will that work together?
Ooh, yes! I need to get a Django and other Python examples going.
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.
Nile CEO here. We work out of the box with Django. We are working on providing examples and tutorials for Django soon.We definitely want to play well with the ecosystem.
I have no need for the product currently but website's really nice with the black-white color schema; I rarely see a website that actually feels as nice. Can't check currently on phone but this is probably nextjs underneath, right?
Readit News
The tenant capabilities are nice to have, but even when building a tenant-focused SaaS not really a big draw. The examples shown even come down to "you can achieve 80% of this by just adding a tenant column everywhere". When comparing this to e.g. Supabase, their autogenerated REST/GraphQL APIs solve a lot more significant pain points, especially when starting out.
That's usually something that I'd outsource as much as possible to Auth0 (yikes, considering the last days), as building out the UIs and state handling for all user auth and management flows is a huge chore. I think recently Clerk has set a new standard on how easy that can be. I'd be surprised if a database product could compete in a meaningful way in that area.
I'm looking forward to see what Nile evolves to! (IIRC Supabase also didn't look that enticing when it first appeared on the map). In general I'm really happy to see databases as such an active space of innovation again.
Nile user permissions are optional. You can decide to use any third-party provider for it. We are in the design phase for permissions at this point. We would love to get your feedback to understand more about your concerns https://github.com/orgs/niledatabase/discussions/159
https://supabase.com/docs/guides/getting-started/architectur...
This is why we don’t run a fork of Postgres, and we lean heavily into extensions rather than customizations. As the docs mention: this forces us compete on experience.
(Speaking here to your point about supabase, not to detract from Nile, which looks very cool)
As this does regional accesses of shared and modifiable data, does Nile implement or guarantee snapshot consistency for cross-shard queries? Citus doesn't have this yet, iirc.
From the docs, I assume Nile does something like the following:
- "smart partitioning" of tables on tenant_id when tenant_id is detected on table creation. These partitions are either region-local when the tenant is located in that region, or foreign tables. (Alternatively, non-local tenant data is replicated with e.g. logical replication/LR, or triggers)
- global tables are replicated across all regions, again presumably with LR
- RLS on the smart partitioned tables, which applies the tenant filter when nile.tenant_id is set.
Do you have any docs where I can read up on this in more detail?
All in all this looks like a real neat project. Congrats on launching.
Congrats on the launch. I would love to try out Nile in the future!
Specifically, Nile lets you do the following - Create a database and start querying it. Nile takes care of adding capacity to tenants as workload increases. - Pay for what you use. You will only pay for what you use. We have plans for pricing where you can pay based on usage per tenant. This will ensure your business value is aligned with the cost of your database. For example, a customer on your free tier may not be an active user and you would not pay for them in Nile. - We have built multitenancy into Postgres and a gateway layer that routes. This helps us to scale to zero with instant availability when you want to scale back up.
- You can create even a million tenants if you have that many customers. - We have built connection pooling into Nile. This helps to provide limitless connections as you grow
I'm still trying to understand the scaling story better. When we say serverless it mentions automatically scaling when it detects some sense of resource pressure. If I have a "hot tenant-database", does that mean this shard will be scaled automatically without impact to existing queries? Or would there be some "blip". I suppose it's unavoidable in edge cases but curious about the regular ones as well.
It's an incredibly cool CX you have here with the automated query routing/tenancy story though, looking forward to what happens in this space.
The first meaning I was familiar with was the idea that there was no long-running process operating a service. This was like a lambda, executing upon a trigger and then stopping.
The second meaning I learned about more recently was the idea of "serverless" being an abstraction layer, where you don't think about what server the service is deployed on (specifically, you get to stop caring about the resources allocated to that server), even though it is deployed as a continuous, long-running process.
I was also only aware of your first definition of serverless.
I absolutely love PlanetScale but having 1 database per client means paying for 1 plan per client. I'm B2B so I have way fewer "clients" but my load is incredibly spiky for each client (75% of the time they have near-0 usage, 20% of the time they have a tiny amount of usage, and the 5% they use a bunch). As it stands right now their heavy load never overlaps so I've been mulling over a move to an RDS cluster where I can run multiple databases on the same hardware.
I'm not super interested in migrating to Postgres (though I think my app would move relatively easily, I don't use anything super MySQL-specific, it's just what I know) but I'll be watching this project as it moves forward. I'd really like to not manage my own DB, it's not where I'm strong and I'd rather focus on other things.
I guess this gets a pass since it's not a "Show HN" but that junk drives me crazy
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
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.
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.