Hacker News new | ask | show | jobs
by brosciencecode 969 days ago
This looks like an interesting take on serverless Postgres! Is this type of multi tenant separation enough for the kinds of users who care about it? I’d imagine a lot of the concerns around multi-tenant would be related to potential application layer bugs that can co-mingle data.
1 comments

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.
Makes sense, but if you're doing multi-tenancy, why not deploy a postgres database for each user so co-mingling is not even possible? That would make on-prem deployments easier to migrate to as well.
> why not deploy a postgres database for each user so co-mingling is not even possible

This is the approach we took and I think it helps with IT review docs.

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.