We use the apartment gem pjungwir mentioned. I guess it works well if you have a small number of customers, each with lots of data. The other way around, lots o

We use the apartment gem pjungwir mentioned. I guess it works well if you have a small number of customers, each with lots of data. The other way around, lots of customers with little data would not scale, I'd say. As with any technique, there's pros and cons. Pros: - When you enter a psql session, you `SET search_path TO customer;` and that's it. No customer_id column in any table you have to remember setting in your WHERE clause. - Same thing for rails console. At the beginning of the session you choose which customer you want to operate on. - Similar for web requests. You just activate the right customer (e.g. based on subdomain) and that's it. Instead of `current_customer.posts.find(params[:id])` you can now simply do `Post.find(params[:id])`. - Data is completely separated. It's almost impossible to have a bug causing data to spill from one customer to the other, which is quite high chance when you always have to remember to load data through the current customer. Cons: - Number of objects (tables, indexes, sequences) is multiplied by number of customers. - Adding a new customer requires `pg_dump` to be present as it dumps the public schema (the blueprint), creates a new schema, and loads the dump into that schema. - Migrations take longer as there are more objects to touch. In our case, the pros outweigh the cons. One further advantage of the separate schemas is that, in theory, we could at any time start using completely separate databases, one for each customer or just one additional for a much larger customer that's eating up all resources on the DB.