Nile: Serverless Postgres for modern SaaS

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.

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

It’s worth mentioning that portability is one of our core Principles at Supabase too:

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)

Thanks sai. Great to hear from you! I have been following PeerDB and you folks are doing great work.

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 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.

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.

Even worse is the Github link to a practically empty repository.

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?

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?

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?

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?

Data isolation, recovery, backups are a big problem in the world of SaaS, especially at huge scale. Companies end up hiring a dedicated infra team to handle such issues.

Technically true, since we did all that with Postgres :)

Nile CEO here. We do offer serverless Postgres but that is where the similarity ends.

We’re the first database that virtualizes tenants into the database. 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.

Here are some examples that can help you to understand the type of use cases. Most applications are multi-tenant and this is what we help with.

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.

Happy to chat more. My email is ram@thenile.dev

Nile CEO here. There are many approaches to doing multitenancy. - You can create one physical DB per tenant - You can place multiple tenants on the same DB

Both approaches have pros and cons. This is exactly what Nile is solving. We want users to not worry about all the operational complexity of picking a choice. You can choose any approach in Nile.

In Nile, the tenant DB is a virtual concept. You can choose to place it on a multitenant DB along with all the other tenants or choose to place it on a dedicated DB. Nile provides a single experience irrespective of your choice and takes care of all the operational complexity. We also go one step further and also let you place a tenant in any location worldwide but still have one Postgres experience.

You can read more about it here https://www.thenile.dev/docs/tenant-management https://www.thenile.dev/docs/tenant-placement

Would love the feedback

Notion does something similar, sharding postgres grouped by their tenants. It takes a huge effort and preparation to get it right, both at the application and infra level. Link: https://www.notion.so/blog/sharding-postgres-at-notion

I'd say it's probably not the typical implementation. Mainly because it's a pain to implement and manage.

I guess that's why this was created though. It's definitely an intriguing tool.

I did shift in past from single database to sharded via citus. The actual migration was smooth, but 6+ months of work went into ensuring compatibility.

There's ways to nearly guarantee compatibility without actually using a sharded approach, like enforcing all tables have a uniform shard key.

> is this how multi-tenancy is typically implemented (a per-tenant-database)?

There's a few different approaches and deciding which to use can be tough. When I was adapting a formerly single tenant Django application to a multi-tenant solution, I went for a "db-per-customer" (with many databases on a single db server) for a few main reasons:

1) Allows you to backup and restore databases on a per customer basis.

2) Helps with IT reviews if you can say "your data exists in its own DB and is not co-mingled with other customers data"

3) Implementation seemed like it was going to be simpler, especially for adapting an existing single tenant application to a multi-tenant one.

4) Makes it easy to migrate existing single tenant-db's to the multi-tenant app.

The main drawback for us I would say is that it makes managing database migrations/schema changes a bit more challenging since you now need to update N db's every time there's a schema change. This was not super difficult though.

Overall I am very happy we decided to go with a multi-db multi-tenancy solution.

Yeah, worked in projects with both of those methodologies. Combining tenants in one database is good for cross tenant aggregation but causes people to reach for...

> brittle permission logic at the application level or complex, hard-to-debug, row-level security policies in databases like Postgres

Separating them into separate databases has its own problems with connection pooling, resource management, and query speed. It's also a pain when you have to combine the data. Then you go down the rabbit hole of ETL and SaaS products with a "scratch" interface that promises to speed things up through (yet another) customer DSL and new naming convention for everything you already know.

A better option is separating tenants by schema. Think about how you switch between schemas in Postgres. Queries look something like this:

> set search_path to public, tenantA; > select * from somewhere as smw inner join elsewhere lsw on smw.id = lsw.somewhere_id;

The somewhere table is in the public schema, elsewhere is in the tenantA schema.

In Rails, there are a couple gems that come to mind for multi-tenancy. acts_as_tenant works exactly like this, by swapping the tenant schema in ActiveRecord (the Rails ORM layer). The ros-apartment gem is another (formerly just 'apartment'). I ran across another gem called 'roomer' too but it is outdated. It works the same way though. You could even roll your own if you insert the logic at the right layer of whatever stack you're using.

Set the tenant at the request level and the ORM auto switches the schema for you. Match a subdomain to the tenant and away you go. You got a SaaS application. edit: And, it'll pass a security audit because of the separation. And you can query across LOB tenant data in a BI front end if you can live without real-time data and build some materialized views; if Redshift and Snowflake are just too expensive.

Using schema separation you get the best of both worlds; smaller data in tenant specific tables with the ability to cross tenant query because they're in the same database. And yes, I'm well aware foreign servers are a thing in Postgres but with sufficiently large data you have to spend more time tuning them for fetch size and indexes to get decent performance. Forget the fact that sometimes you have to implement dynamic SQL using SQL which is a nightmare of repetitious quotation marks with any complex data structure. Foreign servers amplify the escaped quotes. My stomach turns remembering having to write that code...

Is there a npm package for something like this? React/node is not my daily driver.

Sometimes it is. Often it's done in the database itself, but then you have to be very careful you never have a query that returns data that belongs to someone else.

Have you tried Neon recently? There were some big improvments rolled out in the late summer - https://neon.tech/blog/cold-starts-just-got-hot

What cold start times have you experienced? I work at Neon, so I'm more than happy to pass along your experience if you want to share it with me. You can email me at tristan at neon.tech. Or you can reply here.

Nile CEO here. You can place tenants on multitenant DB or a dedicated Postgres DB. Placing the tenants on multitenant DB is the default. This has no cold start time since the instance/container is shared. If you choose to place a tenant on a dedicated tenant DB, you would have cold time of a few seconds. We are building this as we speak and will have more numbers to share soon. However, if you have chosen to place a tenant on a dedicated DB, these typically would be critical customers who are actively using the DB and may never want the instance to go down. We are exploring provisioned compute tokens for this purpose.

Azure SQL Server Hyperscale architecture gives you plenty of scale but does not do anything to help with managing tenants.

I will explain what Nile tries to do. Happy to follow up.

The most foundational element in SaaS is a tenant. It makes a lot of sense to build this core concept into the database. Imagine having a lot of virtual tenant databases that can be co-located on one physical Postgres (multi-tenant) for better cost, and some of them can be placed on a dedicated database for better isolation. The virtual tenant DBs can be located anywhere on the planet for low latency or compliance. The client can route to the right tenant seamlessly without routing logic in the application.

Isolating tenants into their own virtual DBs is great, but you will also want to be able to share data across tenants where it makes sense. Backups should be available for each tenant, and it should be possible to restore them instantaneously. Schema changes should be applied seamlessly across all the tenant DBs, and it should also be possible to do staged rollouts for different tenant tiers. While supporting all this, all the standard SQL capabilities should work across the tenants for admin operations. All the standard Postgres tooling should work. You want the experience of a single Postgres.

This is what Nile tries to achieve. A model that gives you fine-grained control over your tenants. You create, scale, locate, pay all by tenants.

They don’t seem to get into their architecture under the hood. The novel aspect seems to be that they have tenants as a first class member of the database

We do plan to support a bunch of extensions soon. We do support pg_vector at this point. Would love to know if you have any favorite ones. Also, could you share the use case for listen/notify? We currently do not support it but have plans for something that gives you the same functionality.

Currently, we support only AWS but do want to support other cloud providers. Technically, you can even have one DB that spans across cloud providers with your tenants, but we have not yet seen many use cases for multi-cloud.

W.r.t replicating data across tenants, could you give an example use case for it?

Nile CEO here. Yes, you can store embeddings per tenant and search for it. You can read more about vector embeddings and how we support it here https://www.thenile.dev/docs/ai-embeddings

neon and supabase are both the up and comers in the postgres world i think. the real incumbents are the AWS RDSes of the world and their azure and gcp equivalents.

We don't have an official example yet, but I expect it will work. So far every JS framework that uses https://node-postgres.com works great and so no reason to think Drizzle wouldn't.

Nile CEO here. Yes, this is docs, examples and our website right now. Our background is in open source for the last 15 years. We helped build Apache Kafka and grow the community to a very successful one. We believe open source should be done well and hope to consider it once we have the bandwidth to provide DIY ways to run Nile.

This is the docs repo