Multi-tenant & Multi-Region Postgres

I have a SaaS product where we have hundreds of customers in 1 single database. The current database is in MS SQL and we are transitioning to Postgres. The current MS SQL is about 160gb in size.

We are evaluating fly for this product and I wanted to see if there are any suggestions on the architecture for this type of setup on fly. Some of my questions include:

  • Should we break out the database by each of our customers? We have hundreds, not thousands but still sounds like a lot to maintain. Maybe a hybrid approach of dividing customers for every 100 customers or something into a db.
  • What are the cost per region for a db of this size?
  • Can the multi-region handle this type of setup?

Any other recommendation would be great!

Hey there,

  • Should we break out the database by each of our customers? We have hundreds, not thousands but still sounds like a lot to maintain. Maybe a hybrid approach of dividing customers for every 100 customers or something into a DB.

Would you be able to elaborate more on why you’re looking to break your data into multiple databases?

  • What are the cost per region for a DB of this size?

Here’s a link to our pricing page, which should give you a better idea of potential cost:

  • Can the multi-region handle this type of setup?

I can’t say for sure without better understanding your use case and what you’re looking to achieve by going multi-region. Would you be able to provide some additional details on this?

Hey Shaun,

Would you be able to elaborate more on why you’re looking to break your data into multiple databases?

We currently have a large number of customers and I was curious with Fly and its multi-region db, is it better to approach the the db in a multi-tenant app with different databases or even split by schema. So for example, we have all our tenants in 1 large database, would it be advised to keep following that pattern in fly. We do it because it is easier to maintain.

Costs

I understand the cost from the pricing guide, but I was wondering if you have any advice in this area for an app of this size to help minimize cost and maximize performance.

I can’t say for sure without better understanding your use case and what you’re looking to achieve by going multi-region. Would you be able to provide some additional details on this?

Is it possible to schedule a time to discuss this? It may be difficult to do this on a forum.

It’s almost never a better choice to split customers up into dedicated DBs unless you have a really good reason. That becomes a nightmare to manage. If it were me, I’d run a single database for a bunch of customers, then think about spinning up a second one in a different region if there’s a business need for different primary/secondary regions.

For 160GB of data, you’re going to need between 4 and 16GB of RAM most likely. We have example cluster prices, but you can tweak RAM and disk on them very easily. I’d probably start with dedicated-cpu-2x and 4-8GB of RAM and see how it goes.

With that config and 4 GB of RAM, you’re looking at $274/mo for the primary region (one primary, one failover) and $137/mo for each replica region. With 8GB of RAM it’s $334/mo for primary region and $167/mo for the replica regions.

You could split customers across clusters to try and save money but that seems like a headache for relatively little gain.

Yeah I prefer not to split it, it is too much to maintain. And this pricing sounds good. We are spending a small fortune on our MS SQL on azure. I think we could replicate it across 10 data centers and still save money with you guys.

1 Like