News for hackers. Stuff that matters.
Re:Ask HN: Has anybody shipped a web app at scale with 1 DB ... by krainboltgreene on Tuesday May 26, 2020 @12:52AM (#23307538)
> 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.

Re:Ask HN: Has anybody shipped a web app at scale with 1 DB ... by cornishpixels on Tuesday May 26, 2020 @02:06AM (#23307911)
How is it not? Uniqueness would cease to matter between different tenants. They're unique by virtue of using a different database.
Re:Ask HN: Has anybody shipped a web app at scale with 1 DB ... by gomox on Tuesday May 26, 2020 @02:13AM (#23307955)
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.
Re:Ask HN: Has anybody shipped a web app at scale with 1 DB ... by ryanbrunner on Tuesday May 26, 2020 @10:14AM (#23311365)
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.
Re:Ask HN: Has anybody shipped a web app at scale with 1 DB ... by gomox on Tuesday May 26, 2020 @03:04PM (#23315159)
You can probably run the environment itself, but other systems (release management, monitoring, billing, etc) probably rely on the account_id being unique.
Re:Ask HN: Has anybody shipped a web app at scale with 1 DB ... by ehsanu1 on Tuesday May 26, 2020 @01:56AM (#23307855)
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.
Re:Ask HN: Has anybody shipped a web app at scale with 1 DB ... by gomox on Tuesday May 26, 2020 @02:09AM (#23307930)
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.

Re:Ask HN: Has anybody shipped a web app at scale with 1 DB ... by mrunkel on Tuesday May 26, 2020 @02:37AM (#23308090)
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.

Re:Ask HN: Has anybody shipped a web app at scale with 1 DB ... by gomox on Tuesday May 26, 2020 @03:39AM (#23308412)
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?