Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
My startup currently does just this &#x27;at scale&#x27;, which is for us ~150 b2b customers with a total database footprint of ~500 GB. We are using Rails and the Apartment gem to do mutli-tenancy via unique databases per account with a single master database holding some top-level tables.<p>This architecture decisions is one of my biggest regrets, and we are currently in the process of rebuilding into a single database model.<p>FWIW, this process has worked well for what it was originally intended to do. Data-security has a nice db level stopgap and we can keep customer data nicely isolated. It&#x27;s nice for extracting all data from a single customer if we have extended debugging work or unique data modeling work. It saves a lot of application layer logic and code. I&#x27;m sure for the most part it makes the system slightly faster.<p>However as we have grown this has become a huge headache. It is blocking major feature refactors and improvements. It restricts our data flexibility a lot. Operationally there are some killers. Data migrations take a long time, and if they fail you are left with multiple databases in different states and no clear sense of where the break occurred.<p>Lastly, if you use the Apartment gem, you are at the mercy of a poorly supported library that has deep ties into ActiveRecord. The company behind it abandoned this approach as described here: <a href="https:&#x2F;&#x2F;influitive.io&#x2F;our-multi-tenancy-journey-with-postgres-schemas-and-apartment-6ecda151a21f" rel="nofollow">https:&#x2F;&#x2F;influitive.io&#x2F;our-multi-tenancy-journey-with-postgre...</a><p>Happy to expand on this if anybody is interested. It&#x27;s currently a cause of major frustration in my life.