Multi-Tenant Architecture

We’re currently in the process of building out V1 of a new project that was slated to run on AWS Aurora. However, I find Neon very intriguing so had some questions about whether it fits our usage model. The app is a multitenant SaaS app where each tenant environment (ie: prod, dev, qa) is given a schema within Aurora Postgres and a db router determines which schema to route a specific request to.

It appears to me that the best way to handle this is for each tenant to get their own Neon database and then use branching for their environments. Does my understanding of Neon applied to this architecture make sense? It sounds like Neon really does scale to 0 so I assume if only 1 tenant is active, the other tenants are not impacting compute. If this approach makes sense, are there logical or account limits to how many databases can be run under one account?

Edit: after some additional testing it appears branching is related to the project and not the database. I don’t think that has an effect on the use of Neon since it just means I need the pro plan. It appears there are unlimited projects. But how unlimited is unlimited? Let’s say I have 50k tenants does that mean I can basically have 50k projects - one per tenant?

1 Like

I would like to see more clarification around this too … how should I think about a hybrid, pooled, or siloed approach with Neon for a SaaS app?

FWIW, my company (brevity.io) is running a neon db per customer and a branch per environment and it was relatively easy to implement with neon’s APIs.

So far, we think this has been a good approach. Neon also makes it easy to bill your customer based on their DB usage which is nice if you ever want that option.

2 Likes

Hi @alex.gadea ,

Interesting use case. Is it the same or different schema for each tenant?

If it’s the same schema, then branching is a good option. However, if it’s a different schema each time, you might consider using multiple databases within one project.

It’s difficult to say which one is better for your use case. We’ll need to learn more about it to be able to help.

Regarding the number of projects, you can contact our sales team to have unlimited projects.

Below is Neon object hierarchy:

Neon account
    | 
    |- project 
    |      |
    |      |---- primary branch (main) ---- compute endpoint a
    |                |    |
    |                |    |---- roles
    |                |    |---- databases           
    |                |                         
    |                |---- child branch 1 ---- compute endpoint b 
    |                |          |    |
    |                |          |    |---- roles
    |                |          |    |---- databases   
    |                |          |
    |                |          |---- child branch 1.a ---- compute endpoint c 
    |                |                          |
    |                |                          |---- roles
    |                |                          |---- databases

Hi @alex.gadea as a quick follow up to the limitations. We have default limitations in order to prevent abuse but beyond that there are no limits. We already have some individual customers who are reaching close to 20K projects with no signs of slowing! In order to support this we perform extensive capacity testing to ensure a reliable and scalable service.

If you would like to discuss your use case in more detail, feel free to reach out to atli@neon.tech and we can schedule a time to chat.

All good info. Thanks for the insightful comments. A quick summary of the actual use case. Each tenant will start with what we call a 'project" that has their own schema that will be a combination of a base schema that we generate and their own adjustments/additions. Think of it as the tenant deciding they want the base restaurant management app - they will get the schema for the app and then customize it for their needs. They will then push that schema out to new tenants who will also then have the ability to iterate on the schema and it would be cool if these ‘sub-tenants’ had the ability to use branching as well.

From the object hierarchy Raouf provided it sounds like its actually a really good fit to our approach. I wonder whether it would be better for each subtenant to have their own project and instead of branching , they would do something like “fork” from the parent. But I think we need to just jump in and start testing different approaches at this point.

One last question, this may be in your docs, but which hosting provider do you use? If you are on aws, do you support privatelink?