3 ms·
My strategy is using a separate, but equivalent schema for every tenant and setting the tenant context with every request before running queries.
by pvorb 6y ago
My strategy is using a separate, but equivalent schema for every tenant and setting the tenant context with every request before running queries.
- infogulch 6y agoIdeally setting the tenant context happens early during request authorization, is a required to get access to a database connection, and is configured outside the scope of any request business logic.
- pvorb 6y agoYeah, I'm using Java, so in practice this means I extended my JDBC DataSource. On every call to getConnection() it sets the schema.
- ccleve 6y agoThis works and solves a lot of problems. The downside is that schema changes are cumbersome because you have to make them in many places. If you want to roll out a new feature in a shared app which depends on a schema change, it's hard to do without downtime or complicated feature flags.
- hinkley 6y agoIt seems like some continuous deployment strategies could work here, as long as you limit the number of schema changes in flight to a handful. Customer A is running the new schema, so gets one cluster. Customer Z will get migrated in the next hour, and then none of the old system is running.