Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Has anybody shipped a web app at scale with 1 DB per account?

news.ycombinator.com

Post reply on HN
Print view View original

131–140 of 264 posts

Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?

#131

Post by jcims »

krainboltgreene wrote: post #122
gomox wrote: post #110

Earlier 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.

Here I'll give you one: If you want to change a property of the database that will give your specific use improved performance, you have no way to transactionally apply that change. Rolling back becomes a problem of operational scale, rolling out as well. What if you need to release some feature, but that feature requires a database feature enabled? Normally you enable it once, in a transaction hopefully, and then ro…

For this architecture to work you'd likely have to be able to operate more than one release at a time and move customers along with their database. If you're able to do that then this becomes much less of an issue.

Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?

#132

Post by gomox »

krainboltgreene wrote: post #125
thayne wrote: post #38

Earlier quoted context omitted.

It also makes sharding/ horizontal scalability a non-issue, at least until you get a big enough customer.

But like, every database is easy to shard/horizontally scale until you get a big enough customer. Why do the extra leg work?

If you have 500 medium customers and you need to add sharding to a multitenant production behemoth, it's not trivial.

Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?

#133

Post by PeterStuer »

The original design at tasksinabox.com was one DB per tenant. This became untenable due mainly to cost after the business gained traction. After experimenting with a single DB we settled on a sharded approach. This allows us to have different parameterization as needed in terms of performance, release group, availability, location etc.) . A shard can host thousands of customers or just a single one. I think this is for typical B2B SaaS operations the architectural sweet spot.

Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?

#134

Post by JMTQp8lwXL »

thomascgalvin wrote: post #8

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…

Serverless lambdas only re-use connections in certain situations, IIRC. That might not be the "traditional webapp backend", but it's a growing concept.

Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?

#135

Post by ec109685 »

scosman wrote: post #101

I’ve managed a system with millions of users and tens of billions of rows, and I always dreamed of DB per user. Generally, ~1% of users were active at a given time, but a lot of resources were used for the 99% who were offline (eg, indexes in memory where 99% of the data wouldn’t be needed). Learned a few tricks. If this is the problem you're trying to solve, some tips below. Start by optimizing your indexes. Ensure…

It was Expensify: https://blog.expensify.com/2018/01/08/scaling-sqlite-to-4m-q...

Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?

#136

Post by rclayton »

sky_rw wrote: post #108

My 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.…

I totally get why you are doing this, but I would think DB management and migrations would be really troublesome. Do you have a migration framework to manage migrations across all catalogs?

Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?

#137

Post by swlkr »

I worked for a company that did this, we had hundreds of database instances, one per customer (which was then used by each of those customers' employees).

It worked out pretty well. The only downside was that analytics/cross customer stats were kind of a pain.

The customers all seemed to like that their data was separate from everyone else's. This never happened, but if one database was compromised, everyone else's would have been fine.

If I were starting a B2B SaaS today where no customers shared data (each customer = a whole other company) I would use this approach.

Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?

#139

Post by JamesBarney »

We weren't able to find any silver bullets. We used an orm to split applications for non enterprise clients. And then just installed a duplicate application+db in the cloud for enterprise clients and made sure to charge them for it.(30k+ annual subscription fee)

So to upgrade the application we'd upgrade the everyone application and then do the same with each enterprise client. We only had a few.

I'd recommend trying to avoid it if you can, and if you can't charging the appropriate amount of money which is an arm and a leg.

Re: Ask HN: Has anybody shipped a web app at scale with 1 DB per account?

#140

Post by Mooty »

Actually it might have some simple benefits : clients are willing to pay to have a separated database and a separated server from anything else for security purpose. All of our clients at https://www.bluelearning.fr have their own separated DB when they choose it. So far it has been a huge hit, as most of them paid more just for this.
Post reply on HN