When building SaaS, having multiple copies of the same database schema is common. Either because tenants are isolated to individual schema or for sharing.
At Nile, we are building serverless Postgres for modern SaaS. We handle multi-tenant database design by isolating each tenant to a virtual Postgres database. We let users place the tenants on shared or dedicated compute nodes anywhere on the globe. The tenant virtualization design lets developers connect to each tenant database individually, query data for just this tenant, take a backup, restore, upgrade, or perform any other database operation. We aim to provide tenant isolation while still providing the admin simplicity of a single Postgres database.
One of the challenges we had to address was replicating DDLs across all the tenants across the globe and across computes. When developers change their application schema, we need it to succeed or fail on every virtual tenant database and maintain a consistent state at virtually the "same time". We also need to preserve the transactional guarantees that Postgres extends to DDLs.
In this talk we’ll discuss the approach we took at Nile, dive into key challenges and architecture decisions, and share some of the alternatives we rejected and why we chose our specific approach. You'll learn in-depth details of building Postgres extensions, Postgres locking internals and how we handle distributed transaction failures while pretending to be just a normal Postgres.
x.com/gwenshap
Talk from Systems Distributed '24: systemsdistrib...
Join the chat at slack.tigerbee...
18 сен 2024
