Jira Cloud and Confluence use a DB per user architecture at reasonable, but not outrageous, scale. I can't share numbers because I am an ex-employee, but their cloud figures are high enough. This architecture requires significant tooling an I don't recommend it. It will cause you all kinds of headaches with regards to reporting and aggregating data. You will spend a small fortune on vendor tools to solve these problems. And worst of all despite your best efforts you WILL end up with "snowflake" tenants whose schemas have drifted just enough to cause you MAJOR headaches.
Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
111–120 of 264 posts
Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
#112My startup currently does just this 'at scale', 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. This architecture decisions is one of my biggest regrets, and we are currently in the process of rebuilding into a single database model.…
How does the architecture block major refactors or improvements? Are you running a single codebase for all your tenants, albeit with separate schemas for each? Edit: on reading the link you included, it seems like a lot of the problems are on the Rails implementation of the architecture with ActiveRecord and Apartment rather than with the architecture itself.
For me it falls into the category of decisions that are easy to make and difficult to un-make. If for whatever reason you decide this was the wrong choice for you, be in tech needs (e.g. rails) or business needs, merging your data and going back into a codebase to add this level of filtering is a massive undertaking.
Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
#113No, but previous workplace did fake it with a postgres-compatible front end (in node.js) which pointed to per-customer postgres schema with no data, but views/etc pointing to a multi-tenant schema with the actual data. Between the views and the fake front-end we could isolate customer data and provide hierarchical data access, allowing our customers to point pg-compatible tools to access their data.
I suspect there was negative ROI, and the DBAs avoided me.
Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
#114My startup currently does just this 'at scale', 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. This architecture decisions is one of my biggest regrets, and we are currently in the process of rebuilding into a single database model.…
The link failed to medium for me. Would you mind describing in a little more detail some things?
What DB are you using?
How mature are your automation tools for managing these DB instances?
Do you use a “single” DB server instance with a database defined per customer?
Do you require all your customers to have identical schema, and do upgrade them all irrespective of individual customer concerns?
Thanks in advance!
Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
#115Earlier quoted context omitted.
How does the architecture block major refactors or improvements? Are you running a single codebase for all your tenants, albeit with separate schemas for each? Edit: on reading the link you included, it seems like a lot of the problems are on the Rails implementation of the architecture with ActiveRecord and Apartment rather than with the architecture itself.
For me it falls into the category of decisions that are easy to make and difficult to un-make. If for whatever reason you decide this was the wrong choice for you, be in tech needs (e.g. rails) or business needs, merging your data and going back into a codebase to add this level of filtering is a massive undertaking.
Indeed, but if you are making a B2B enterprise/SMB SaaS, I think you are most likely to regret the opposite choice [1][2]. A lot of companies run a single instance, multitenant application and have to develop custom sharding functionality down the road when they realize the inevitable: that most joins and caches are only needed on strict subsets of the data that are tenant specific.
If you get successful enough in this type of application space, you reach a mature state in which you need to be able to:
* Run large dedicated instances for your largest customers, because either their performance or security requirements mandate it.
* Share resources among a large number of smaller customers, for efficiency and fault tolerance reasons.
You can get there in two ways:
* You start with a massive multi tenant application, and you figure out a way to shard it and separate in pieces later.
* You start with multiple small applications, and you develop the ability to orchestrate the group, and scale the largest of them.
I would argue the latter is more flexible and cost efficient, and requires less technical prowess.
Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
#116Earlier quoted context omitted.
I don't know your application enough to comment, but that seems like an extreme version of what I'm proposing, which would be to share application and DB servers between customers, but not application code and databases (i.e. you can still run 3 customers on the same EC2 and RDS instances, they just have separate application code and separate database schemas). One of the main benefits, like you describe, is lowered…
The way you are thinking would be much cheaper than what I'm doing with the downside that clients data exists on the same server (but maybe they won't care) and the fact that a performance issue for one client can impact other clients. I haven't found an AWS account per customer to be to bad to manage yet and makes keeping track of your AWS spend per client simple. It's also trivial to run your resources in say Sydne…
If it works, then it works :)
Company B I mentioned above still runs location specific infrastructure, but each one of these clusters can host several customers. Of course there is some overhead (i.e. very new regions sometimes operate at a loss if there is not a critical mass of customer in that cluster, but they are subsidized by more profitable regions until they reach a critical mass of customers to pay for the whole cluster costs).
Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
#117Disclosure: I work on Google Cloud. tl;dr: Wait until you need it, but there are good reasons for it! Since I didn’t see anyone mention it, the term I’ve seen a lot of people use for this pattern is “multi single tenant”. Part of the reason we have Tenant Projects [1] is precisely so you can do a 1:1 mapping of “Customer A can have different controls, settings, and blast radii from Customer B”. Many of our first-part…
Somewhat tangetial: If we use something like bigquery which handles multitenancy well, there still doesn't appear to be a good way to expose it to a customer directly (say for a BI tool). Like with a simple username/pwd. Any pointers?
In GCP you can grant permissions to entities outside of your org, either to users or to an external service account. This is how things like Cloud Build and other services that require Google to have access to resources inside your projects work.
Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
#118Earlier quoted context omitted.
For me it falls into the category of decisions that are easy to make and difficult to un-make. If for whatever reason you decide this was the wrong choice for you, be in tech needs (e.g. rails) or business needs, merging your data and going back into a codebase to add this level of filtering is a massive undertaking.
Indeed, but if you are making a B2B enterprise/SMB SaaS, I think you are most likely to regret the opposite choice [1][2]. A lot of companies run a single instance, multitenant application and have to develop custom sharding functionality down the road when they realize the inevitable: that most joins and caches are only needed on strict subsets of the data that are tenant specific. If you get successful enough in th…
You can always take a multi-tenant system and convert it into a single-tenant system a lot more easily. First and foremost, you can simply run the full multi-tenant system with only a single tenant, which if nothing else enables progressive development (you can slowly remove those now-unnecessary WHERE clauses, etc).
Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
#119Earlier quoted context omitted.
Indeed, but if you are making a B2B enterprise/SMB SaaS, I think you are most likely to regret the opposite choice [1][2]. A lot of companies run a single instance, multitenant application and have to develop custom sharding functionality down the road when they realize the inevitable: that most joins and caches are only needed on strict subsets of the data that are tenant specific. If you get successful enough in th…
You can always take a multi-tenant system and convert it into a single-tenant system a lot more easily. First and foremost, you can simply run the full multi-tenant system with only a single tenant, which if nothing else enables progressive development (you can slowly remove those now-unnecessary WHERE clauses, etc).
True, but:
In my experience by the time you reach this point you have a lot of operational complexity because you and your team are used to your production cluster being a single behemoth, so chances are it's not easy to stand up a new one or the overhead for doing so is massive (i.e. your production system grew very complex because there is rarely if ever a need to stand up a new one).
Additionally, a multi tenant behemoth might be full of assumptions that it's the only system in town therefore making it hard to run a separate instance (i.e. uniqueness constraints on names, IDs, etc).
Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?
#120If 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…
I think the standard term is "tenant" for that organizational level, no?