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.
Nile lets you do this without incurring the operational complexity of managing multiple databases. We let you place the virtual tenant DB either on one multitenant Postgres DB or a dedicated Postgres. So, you can actually create a dedicated one for each of your tenant in Nile but interact with them like a single Postgres instance. We take care of schema updates across them, client-side routing and metadata management
> We let you place the virtual tenant DB either on one multitenant Postgres DB or a dedicated Postgres.
Sounds promising, but by "a dedicated Postgres." do you mean a different server or just a different db on the same server? I'm trying to get at how the cost would change between the two solutions. Right now we can run N databases on the same Postgres server for roughly the same cost as running a single multitenant db. Switching to "server per customer" seems like it would be cost prohibitive.
We are going to support a database in the same server initially but could also provide dedicated server in the future. The nice thing about Nile's design is that we can provide different placements for different cost profiles with the developer experience of a single Postgres instance.
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.
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.
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 doesn't necessarily mean that any user could pick up and switch to a different PG instance, as such a young provider maybe look at having some docs for migrating off-platform as a sort of assurance. Maintaining those docs might also help you prevent adding or changing things that would introduce lock-in, it should be a consideration for every feature or API change.
Agree. We will prioritize how to migrate from Nile. At the Postgres level we don't want any lock-ins. We would have APIs that simply SaaS workflows that users may choose to use.
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.
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.
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
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.
