31–40 of 264 posts
https://rubygarage.org/blog/three-database-architectures-for...
I'm not sure if Roam technically uses separate databases, but it certainly calls each user's environment a "database." They're on Firebase (Cloud Firestore?) though, so it might just be a way of naming things and not a true db-per-user model.
We've never lost a single piece of data since we started using it.
https://docs.microsoft.com/en-us/azure/sql-database/sql-data...
Schema migrations are kind of a pain, we roll out changes, so on auth there is this blue/green decision.
Custom fields in EAV data-tables or jsonb data.
Backups are great, small(er) and easier to work with/restore.
Easier to move client data between PG nodes. Each DB is faster than one large one. EG: inventory table is only your 1M records, not everyone's 600M records so even sequential scan queries are pretty fast.
The biggest advantage is flexibility to handle customers requirements (e.g. change management might have restrictions on versioning updates) and reduced impact of any failures during upgrade processes. It's easier to roll out upgrades progressively with proven conventional tools (git branches instead of shoddy feature flags). Increased isolation is also great from a security standpoint - you're not a where clause away from leaking customer data to other customers.
I would go as far as saying this should be the default architecture for enterprise applications. Cloud infrastructure has eliminated most of the advantages of conventional multitenancy.
If an account is a single user then no.
PS: I have a quite a lot of experience with this so if you would like more details just ask.
Yes, for multi-tenancy. Database per tenant works alright if you have enterprise customers - i.e. in the hundreds, not millions - and it does help in security. With the right idioms in the codebase, it pretty much guarantees you don't accidentally hand one tenant data belonging to a different tenant. MySQL connections can be reused with database per tenant. Rack middleware (apartment gem) helps with managing applying…
The inability to reuse database connections would be a huge performance hit. In a traditional webapp backend, you have a pool of connections to the database. User01 hits your service, and grabs a connection off the pool. User02 does the same, and so on. These connections get put back in the pool for reuse once a user is done with them. In your design, every time a user hits your service, a new connection, specific to…
> In your design, every time a user hits your service, a new connection, specific to that user, will have to be made. This will incur network traffic and the overhead of logging in to the DBMS. If connecting to your DB is significantly increasing your page times, you've got seriously fast pages. Even back when I was working with a MySQL database regularly in 2010, connect + login was 5 ms at maximum (and I think it w…
I try to get all my endpoints under 10ms! 5ms per call would be huge.
(Obviously I can't succeed all the time, but 5ms is big numbers imo)
If an "account" is an "enterprise" customer (SMB or large, anything with multiple user accounts in it), then yes, I know at least a few successful companies, and I would argue in a lot of scenarios, it's actually advantageous over conventional multitenancy. The biggest advantage is flexibility to handle customers requirements (e.g. change management might have restrictions on versioning updates) and reduced impact of…