Hacker News new | ask | show | jobs
by lemiffe 2218 days ago
We use a database per account, it is necessary for some ISO (and other) certifications to have single-tenant DBs.

Of course this requires a bunch of extra tooling, like upgrade scripts that don't ALTER tables directly but rather lock-copy-delete-rename, etc.

There are many tools out there which help out with this, and whatever we couldn't find we built ourselves. Tools like JOOQ can update code entities based on the database, so a database-first approach is what we used, but you can go either way.

The benefit of this approach is ultimately security and less multi-tenant catastrophes leaking data from customers, etc.

1 comments

Can you explain why the ALTER approach isn't feasible? If you are locking anyway, is it not the same thing?
My mistake, I didn't check before posting.

The use case was: Keep the table online and don't bring down the Galera cluster (which happened when running an ALTER on a table with millions of rows).

We went for pt-online-schema-change (from Percona) which copies, alters the new table, keeps them in sync, and then replaces it. All automated which is pretty sweet.

One of the answers on here has more info:

https://stackoverflow.com/questions/463677/alter-table-witho...