3 ms·
So satisfying when you read an article that just happens to be pitched at exactly the stage of learning you're at. Every single bit of advice in here is somethi
by aidos 11y ago
So satisfying when you read an article that just happens to be pitched at exactly the stage of learning you're at. Every single bit of advice in here is something I can use today without any thought.
@fpilipe, you mention you use one schema per customer. I'm curious as to how many people do this and how well it works for them. Any thoughts?
- pjungwir 11y agoIt's not my usual way of doing things, but there is a Rails gem[1] for this that looks pretty nice. [1] https://github.com/influitive/apartment https://github.com/influitive/apartment
- fphilipe 11y agoWe 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.