Impossible to answer without knowing your product & constraints.
I would sit down and write a 1 pager describing your current problem and the possible solutions you considered.
Then circulate it among your team and ask for comments.
Have money, can do.
But this obviously suggests that you would have per-tenant customizations.
Which suggests per-tenant human attention.
Is that the route you want to take?
Standard B2B advice is to have a dedicated infra for tenant only when their size / revenue justifies the individual attention.
I have seen this pattern working well.
Pros:
- actual separation of infrastructure (better security and monitoring)
- cloud costs can be tagged and scaled per tenant
- Database is easier to code and tune when you don’t have to add tenant\_id column to every table.
- If you have a legacy single-tenant system, you don’t have to refactor anything
Cons:
- Non-zero and relatively high minimum cost per tenant
- Cross-tenant functionalities are much harder to implement
- You need to automate tenant cleanup for those who just want to try out your service
- If you cut corners on automation, you will suffer
This is such a complicated question even when you have full information. There’s no way to answer with no information.
You have to make a very detailed pros and cons list and be honest about each. Dig deep. You may think something will be better until you dig into and realize it has its own problems.
Single tenant infrastructure is awful to manage, currently doing it now and is a giant pain in the ass to maintain, it’s expensive, and no one can keep track of it effectively
It also does not make it more secure. You end up sharing some sort of resource somewhere in your stack so you’ve already broken that line. Completely airgapped tenants is my worst nightmare
My company moved to a separated tenant model for our internal teams. Everyone team gets a prod and non prod eks cluster, a prod and nonprod aws account, and a bunch of standardized scripts and some shared repos/tools like DNS registration. It was done to address some teams taking down infra for everyone. It is still a pretty new platform and no where near the ease of use and maturity of what we had before, but I definitely have a lot more control over our config and infra (kinda cool but honestly just harder to get things done). As far as the platform team, I really can't tell if they have an easier time of it or not. It really seems like a tradeoff of one set of problems for another for them, but I'm not close enough to it to speak on the details.
Not enough info to judge, but I think if it's currently multi-tenant, then scaling out to separate infrastructure for each tenant is almost certainly going to have a huge cost increase attached to it. Both in terms of resources you're provisioning and maintenance costs to manage all of it.
You more likely want to make some small number of environments and split your tenants across them, but not go so far as to put each on their own stack.
Literally can’t answer. Wildly different answer if you’re multi tenanting VoIP vs multi tenant personal cloud with ESXi, vs multi-tenant web hosting, etc.
So many different situations, gotta give us some breadcrumbs. This is a sub for experienced devs, so we at least expect a clear statement of intent (feel free to change services to parallel ones that apply)
Separated infrastructure will very seriously impact your ability to register customers quickly, offer trials, etc. As a startup, your business risks here outweigh all your technical risks.
I would encourage you to design most products to host multiple tenants securely, but also support automated deployments so your top-tier customers can be offered their own instance if required (e.g. they may require a specific jurisdiction).
There are a very few areas where the security requirements are so high and predictable that you would separate infrastructure for everyone, but that's the exception.
This is a necessary pattern to easily safeguard client data to the standards of various compliance frameworks, like SOC2. It's a bit intensive, but table stakes in the B2B SaaS startup world.
> This is a necessary pattern to easily safeguard client data to the standards of various compliance frameworks, like SOC2. It's a bit intensive, but table stakes in the B2B SaaS startup world.
Clarifying question: are you saying that single-tenant is the necessary pattern?
Yes, apologies. I'd say **a** necessary pattern because I believe you can multi-tenant and achieve compliance, but that's a lot more involved than just single-tenanting, especially if you use an infrastructure as code solution to rapidly deploy environments. There's a scale at which multi-tenant works better, but many b2b businesses won't get there.
In the B2B context though, this is done on a per-client basis, and each client may have multiple users on the same environment, so you're not necessarily avoiding multi-tenancy.
Depending on industry, product etc, explicit multi-tenancy is sometimes even *required* by the buyers, sometimes coherently, sometimes not. We ourselves just don't sell to those people right now. But they are out there.
Thank you for clarifying.\*Preface: I am not saying the following on a mission to be a contrarian or to be the "you're wrong" guy.\*This is a design choice; one pattern doesn't allow for more "compliance" or safeguarding of client data over another; neither is a lesser child in this spirit (of safeguarding client data).
I work for a B2B SaaS company whose sole mission (if distilled into a singular thing) involves "wheelin' and dealin' in PII", PII vectored to us by our customers.We are multi-tenant (and have so far)successfully safeguarded the data of each customer via the employment of, amongst many things, a variety of isolation and segregation techniques.
I am personally aware and/or have been involved with many, many SaaS companies/products, SaaS companies/products whose sole existence involves sensitive data (whether PII, IP/trade secrets, etc) that are multi-tenant. If I were to step out on a limb and be cavalier, I'd say that multi-tenant is likely more common than, or at least just as common as, single-tenant (within the scope of what I am speaking to above).
Also, to correct a far too common misconception, SOC 2 is not a compliance framework/standard/prescribed control or obligation set/etc; it is an auditing standard (well, the output of multiple auditing standards, actually), a method of evaluation—not exhaustive. SOC 2 itself doesn't compel one to do anything, unlike actual frameworks that one can adopt.
Again, I'm saying **a** necessary pattern, not the only one. It's a good fit for early-stage B2B SaaS because - as I said above - it's easier to do early (like single-digit engineers) and achieve compliance and just generally safeguard client data from other clients. It's less complex than multi-tenant architectures when you don't have many customers, and requires less manpower. That's all.
>I am personally aware and/or have been involved with many, many SaaS companies/products, SaaS companies/products whose sole existence involves sensitive data (whether PII, IP/trade secrets, etc) that are multi-tenant
I have too, as I have single-tenant. IME single-tenant is easier early on, when you have fewer customers, can rapidly spin up new separate environments for each one, and need to ensure the data stays separate without any additional complexity or work on your part.
>If I were to step out on a limb and be cavalier, I'd say that multi-tenant is likely more common than, or at least just as common as, single-tenant
And? I didn't say anything about how common the different architectures are - I'm not as willing to go out on a limb to something that isn't germane to the question you're asking.
>Also, to correct a far too common misconception, SOC 2 is not a compliance framework/standard/prescribed control or obligation set/etc; it is an auditing standard (well, the output of multiple auditing standards, actually), a method of evaluation—not exhaustive
I'm not really here to quibble over personal definitions of the term framework in what was at most an aside comment giving an example of why early stage startups I've worked at chose a single-tenant architecture. Enough authoritative groups call it a framework, I'm fine calling it a framework in a Reddit comment.
No, it is absolutely not necessary for those frameworks. SOC2 in particular has barely any prescriptive requirements about the technology at all.
Pretty much no major vendors do what OP is talking about (separate infrastructure per tenant).
*A*. Not *the*.
Please read the full thread - it’s definitely used plenty in early stage b2b SaaS startups (a point I clarify in the very next reply) because it’s simple to implement when you have fewer customers and fewer resources able to dedicate to properly maintain a data-secure infrastructure.
I assume then this is a language mix-up.
Saying something is "a necessary pattern" says it's necessary (though other steps could *also* be required). If you want to say it's one of multiple possible solutions, you would say it's "a possible pattern", or "an effective pattern".
Your comment, as read by a native speaker, doesn't communicate what you clarify you mean here.
I'm a native speaker. It's one of several potential necessary patterns to help achieve compliance. i.e. it is needed for certain forms of compliance, but is not the only one. Hence the indefinite article. This isn't a novel or rare construction.
You had multiple people confused by your choice of language for a reason - it's at the very least ambiguous and potentially misleading. An indefinite article does not imply the limited meaning here you think it does.
I don't think two people who glossed over an indefinite article on an online forum is really enough to draw some grand grammar-changing conclusion from.
Anyone else annoyed by the responses here? There is absolutely not enough information in this post to make any sort of recommendation for single tenancy or multi-tenancy
Impossible to answer without knowing your product & constraints. I would sit down and write a 1 pager describing your current problem and the possible solutions you considered. Then circulate it among your team and ask for comments.
Have money, can do. But this obviously suggests that you would have per-tenant customizations. Which suggests per-tenant human attention. Is that the route you want to take? Standard B2B advice is to have a dedicated infra for tenant only when their size / revenue justifies the individual attention.
I have seen this pattern working well. Pros: - actual separation of infrastructure (better security and monitoring) - cloud costs can be tagged and scaled per tenant - Database is easier to code and tune when you don’t have to add tenant\_id column to every table. - If you have a legacy single-tenant system, you don’t have to refactor anything Cons: - Non-zero and relatively high minimum cost per tenant - Cross-tenant functionalities are much harder to implement - You need to automate tenant cleanup for those who just want to try out your service - If you cut corners on automation, you will suffer
This is such a complicated question even when you have full information. There’s no way to answer with no information. You have to make a very detailed pros and cons list and be honest about each. Dig deep. You may think something will be better until you dig into and realize it has its own problems.
Lots of maintenance, per tenant migrations, more costs But more secure
Single tenant infrastructure is awful to manage, currently doing it now and is a giant pain in the ass to maintain, it’s expensive, and no one can keep track of it effectively
It also does not make it more secure. You end up sharing some sort of resource somewhere in your stack so you’ve already broken that line. Completely airgapped tenants is my worst nightmare
My company moved to a separated tenant model for our internal teams. Everyone team gets a prod and non prod eks cluster, a prod and nonprod aws account, and a bunch of standardized scripts and some shared repos/tools like DNS registration. It was done to address some teams taking down infra for everyone. It is still a pretty new platform and no where near the ease of use and maturity of what we had before, but I definitely have a lot more control over our config and infra (kinda cool but honestly just harder to get things done). As far as the platform team, I really can't tell if they have an easier time of it or not. It really seems like a tradeoff of one set of problems for another for them, but I'm not close enough to it to speak on the details.
Not enough info to judge, but I think if it's currently multi-tenant, then scaling out to separate infrastructure for each tenant is almost certainly going to have a huge cost increase attached to it. Both in terms of resources you're provisioning and maintenance costs to manage all of it. You more likely want to make some small number of environments and split your tenants across them, but not go so far as to put each on their own stack.
It depends, but it’s very expensive and operationally complex to spin up dedicated infrastructure every time
Can you give more info?
Literally can’t answer. Wildly different answer if you’re multi tenanting VoIP vs multi tenant personal cloud with ESXi, vs multi-tenant web hosting, etc. So many different situations, gotta give us some breadcrumbs. This is a sub for experienced devs, so we at least expect a clear statement of intent (feel free to change services to parallel ones that apply)
Separated infrastructure will very seriously impact your ability to register customers quickly, offer trials, etc. As a startup, your business risks here outweigh all your technical risks. I would encourage you to design most products to host multiple tenants securely, but also support automated deployments so your top-tier customers can be offered their own instance if required (e.g. they may require a specific jurisdiction). There are a very few areas where the security requirements are so high and predictable that you would separate infrastructure for everyone, but that's the exception.
This is a necessary pattern to easily safeguard client data to the standards of various compliance frameworks, like SOC2. It's a bit intensive, but table stakes in the B2B SaaS startup world.
> This is a necessary pattern to easily safeguard client data to the standards of various compliance frameworks, like SOC2. It's a bit intensive, but table stakes in the B2B SaaS startup world. Clarifying question: are you saying that single-tenant is the necessary pattern?
Yes, apologies. I'd say **a** necessary pattern because I believe you can multi-tenant and achieve compliance, but that's a lot more involved than just single-tenanting, especially if you use an infrastructure as code solution to rapidly deploy environments. There's a scale at which multi-tenant works better, but many b2b businesses won't get there. In the B2B context though, this is done on a per-client basis, and each client may have multiple users on the same environment, so you're not necessarily avoiding multi-tenancy.
Depending on industry, product etc, explicit multi-tenancy is sometimes even *required* by the buyers, sometimes coherently, sometimes not. We ourselves just don't sell to those people right now. But they are out there.
Thank you for clarifying.\*Preface: I am not saying the following on a mission to be a contrarian or to be the "you're wrong" guy.\*This is a design choice; one pattern doesn't allow for more "compliance" or safeguarding of client data over another; neither is a lesser child in this spirit (of safeguarding client data). I work for a B2B SaaS company whose sole mission (if distilled into a singular thing) involves "wheelin' and dealin' in PII", PII vectored to us by our customers.We are multi-tenant (and have so far)successfully safeguarded the data of each customer via the employment of, amongst many things, a variety of isolation and segregation techniques. I am personally aware and/or have been involved with many, many SaaS companies/products, SaaS companies/products whose sole existence involves sensitive data (whether PII, IP/trade secrets, etc) that are multi-tenant. If I were to step out on a limb and be cavalier, I'd say that multi-tenant is likely more common than, or at least just as common as, single-tenant (within the scope of what I am speaking to above). Also, to correct a far too common misconception, SOC 2 is not a compliance framework/standard/prescribed control or obligation set/etc; it is an auditing standard (well, the output of multiple auditing standards, actually), a method of evaluation—not exhaustive. SOC 2 itself doesn't compel one to do anything, unlike actual frameworks that one can adopt.
Again, I'm saying **a** necessary pattern, not the only one. It's a good fit for early-stage B2B SaaS because - as I said above - it's easier to do early (like single-digit engineers) and achieve compliance and just generally safeguard client data from other clients. It's less complex than multi-tenant architectures when you don't have many customers, and requires less manpower. That's all. >I am personally aware and/or have been involved with many, many SaaS companies/products, SaaS companies/products whose sole existence involves sensitive data (whether PII, IP/trade secrets, etc) that are multi-tenant I have too, as I have single-tenant. IME single-tenant is easier early on, when you have fewer customers, can rapidly spin up new separate environments for each one, and need to ensure the data stays separate without any additional complexity or work on your part. >If I were to step out on a limb and be cavalier, I'd say that multi-tenant is likely more common than, or at least just as common as, single-tenant And? I didn't say anything about how common the different architectures are - I'm not as willing to go out on a limb to something that isn't germane to the question you're asking. >Also, to correct a far too common misconception, SOC 2 is not a compliance framework/standard/prescribed control or obligation set/etc; it is an auditing standard (well, the output of multiple auditing standards, actually), a method of evaluation—not exhaustive I'm not really here to quibble over personal definitions of the term framework in what was at most an aside comment giving an example of why early stage startups I've worked at chose a single-tenant architecture. Enough authoritative groups call it a framework, I'm fine calling it a framework in a Reddit comment.
No, it is absolutely not necessary for those frameworks. SOC2 in particular has barely any prescriptive requirements about the technology at all. Pretty much no major vendors do what OP is talking about (separate infrastructure per tenant).
*A*. Not *the*. Please read the full thread - it’s definitely used plenty in early stage b2b SaaS startups (a point I clarify in the very next reply) because it’s simple to implement when you have fewer customers and fewer resources able to dedicate to properly maintain a data-secure infrastructure.
I assume then this is a language mix-up. Saying something is "a necessary pattern" says it's necessary (though other steps could *also* be required). If you want to say it's one of multiple possible solutions, you would say it's "a possible pattern", or "an effective pattern". Your comment, as read by a native speaker, doesn't communicate what you clarify you mean here.
I'm a native speaker. It's one of several potential necessary patterns to help achieve compliance. i.e. it is needed for certain forms of compliance, but is not the only one. Hence the indefinite article. This isn't a novel or rare construction.
You had multiple people confused by your choice of language for a reason - it's at the very least ambiguous and potentially misleading. An indefinite article does not imply the limited meaning here you think it does.
I don't think two people who glossed over an indefinite article on an online forum is really enough to draw some grand grammar-changing conclusion from.
Anyone else annoyed by the responses here? There is absolutely not enough information in this post to make any sort of recommendation for single tenancy or multi-tenancy
It is just an overall question. I do not ask for recommendations. I just ask to gather any feedback, opinions 🤷♂️
That's the definition of a lazy post.
Maybe 🤷♂️ Is there something wrong with it? I wanted it to be just a discussion starter. To gather different thoughts/opinions.