Hacker News Reader

Comment by cornishpixels | Hacker News Reader

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

View on HN

> You can always take a multi-tenant system and convert it into a single-tenant system a lot more easily.

This is not true if your primary keys are int or bigint.

It's also not true if you have any sort of unique indexes that are scoped to a table.

I think you are talking about problems going from multiple single-tenant systems to a single multi-tenant system. You parent is talking about the opposite.

No.

For example, HubSpot runs a multitenant system. URLs look like:

https://app.hubspot.com/section/$ACCOUNT_ID/etc/etc

In the simple, YAGNI implementation of this, when you create a new HubSpot account, most likely that will insert a new row into the accounts table, and the auto generated ID of that row will be your account ID. Therefore you need uniqueness to be enforced at that level.

If you want to start running a separate copy of the system, you need to refactor the system to move that sequence out of the database so that two different customers running on different clusters don't end up with the same account ID. This is just an example, but there are many problems like this that are caused by the assumption that the production system is a single unique system.

There are many ways to solve this that don't require uniqueness across all systems.

https://${customer}.hubspot.com/... https://app.hubspot.com/${customer}/...

You'd do this at the proxy/forwarder level.

Everything has a solution, but want to bet that at least 20 different internal systems at HubSpot assume that the account ID in that URL is globally unique?

How is it not? Uniqueness would cease to matter between different tenants. They're unique by virtue of using a different database.

See my sibling comment with the Hubspot example. Even though the system might work internally, other things will break if you start having duplicate account IDs because other systems don't think of the account ID as a cluster-local identifier, but as a global one.

Just thinking through this, but if it's an entirely separate environment, just host it on a separate subdomain and the account id becomes irrelevant. If you have a functioning staging environment, you already have the ability to run an isolated environment without issue, this is just a different application of the same idea.

You can probably run the environment itself, but other systems (release management, monitoring, billing, etc) probably rely on the account_id being unique.

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

Some of the issues I see in one of my projects is high interactivity between accounts. E.g. if account 1 'sends' something to account 2 both of the shared/separate db instances need to be up or there'll need to be some kind of queueing mechanism.

That's hard enough and then add to it that most clients want to BYOK to those instances

High interactivity between accounts is a good reason to not adopt the proposed multi-single-tenant architecture. The scenarios discussed are B2B enterprisey apps in which the environments are essentially independent from each other.

Reply on news.ycombinator.com