Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
The inability to reuse database connections would be a huge performance hit.<p>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.<p>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.<p>If you&#x27;re thinking about using something like SQLite, you will hit a hard wall when the OS isn&#x27;t able to open any more file descriptors, as well.<p>Like you said, DB administration will be a huge pain in the ass. Rather than having Flyway or Liquidbase or whatever run a migration on one database, you&#x27;ll have to run it on thousands of databases. There will be significant downtime when your databases are not in a consistent state with one another. There will also be bloat from the migration tool&#x27;s record keeping, which will be duplicated for every user, rather than every database.<p>A lot of the tools a database gives you for free will also need to be implemented in application logic, instead. For example, you might want to run a query that says &quot;show me every user using more than 1GB of storage,&quot; but under your schema, you&#x27;ll have to log into every user&#x27;s database individually, determine storage used, and add it to an in-memory list.<p>If you ever want to allow users to collaborate, you will end up replicating the owner_id field type metadata anyway, and the entire benefit of this schema will evaporate.<p>Most frameworks are not set up to handle this style of database access, either. I don&#x27;t use Rails, but Spring Boot would fight you every step of the way if you tried to do this.