Migration to v2 platform architecture

[thebengeu]

In our previous platform architecture, our Storage, Realtime, and connection pooler (PgBouncer) services were bundled together, with a single instance of each service per project.

For our v2 architecture, we’ve “unbundled” these services, moving to a multi-tenant model, where a single instance of each service serves many projects:

This frees up as much resources as possible for your Postgres databases, while enabling us to offer more resource intensive features for these services, and opens the door to capabilities such as zero-downtime scaling.

With Supavisor replacing PgBouncer, along with some other key optimizations, the final pieces of our v2 architecture are now ready.

Paid plan rollout (completed)

We’ve already fully rolled out our v2 architecture to paid plan projects. You now have more resources available, for the same price that you’ve been paying.

Free plan gradual rollout (20 March 2024 onwards)

• 20 March 2024: Newly created or unpaused projects will use v2 architecture
• 28 March 2024: Existing projects will start being migrated to v2 architecture

This will be a gradual rollout - we will email you at least one week before your project is scheduled to be migrated.

Your action for projects scheduled to be migrated

For newly created or unpaused projects on the Free Plan, no action is required.

For existing projects on the Free Plan, up to a few minutes of downtime is expected for the migration. For each of your projects, we’ll identify the 30-minute maintenance window where your project had the least database queries over the previous 10 weeks.

You have two choices:

• Automatic Migration: If you don't take any action, we plan to do the migration automatically during that maintenance window with the least historical activity.
• Manual Migration: Any time before that, you can go to Project Settings > General to see whether/when the maintenance window is scheduled (timings will also be included in the email). There, you may choose to manually restart the project yourself, at a time that is convenient for you. Your project will be restarted on v2 architecture.

[ImSingee]

Curiously: I'm on paid plan and havn't experienced any downtime. But you point out that free plan projects will have several minutes downtime. Is there any archetecture difference between free and paid plan projects?

[thebengeu]

Yes, there may be architecture differences between free and paid plan projects, due to differing resource constraints, extra features offered, uptime SLAs, etc. Such architecture changes are also subject to changes.

[mkmoisen]

How do we upgrade our local development environments to use the new v2 architecture?

[thebengeu]

The v2 architecture changes are mainly relevant for the Supabase hosted platform. Since so many projects are hosted there, moving to a multi-tenant model, where a single instance of each service serves many projects, is a significant optimization.

Conversely, each local development environment serves a single project, so using a similar multi-tenant architecture as on the Supabase hosted platform would add complexity, such as additional databases and API calls needed to store tenant information, which aren't necessary for the single-tenant case.

[mshamia]

Is the change only on platform architecture, with no change related to the code?

[thebengeu]

Yes, purely architectural, doesn't involve any code changes from our users.

[ShJavokhir]

This Migration wasn't succesfull on my project and causing problem in production

[thebengeu]

Hey @ShJavokhir , the error messages about running database migrations aren't directly related to the v2 migration itself. What appears to have happened is that the database migrations were first attempted when the database wasn't fully up yet, so it wasn't successful, and you can see that the migrations do succeed a few seconds later.

[andrewrosss]

Is a regression in Disk IO consumption expected with the migration to v2 platform architecture?

I have a small app that I run on supabase which I built for myself (the tables are small and the usage is light), however I've started seeing a warning in the dashboard (and via email):

Disk IO budget is being consumed.

Your project is using its Disk IO budget and may become unresponsive if fully consumed.

My project is on a free plan and was slated for migration to v2 platform architecture from 2024-05-21 09:00 to 09:29 UTC.

Upto May 21st (the date of scheduled migration) the Disk IO usage for this project was ~1% everyday, however, since the 21st it's shot up to between 25% and 45%.

.

This is in no way a complaint — I really like the platform, and I'm a free-tier customer so how much can I really complain lol

That said, I'm wondering:

1. Is this expected?

2. If so, should free-tier users just expected this to be the "new normal"? (I.e., that the projects should expect to very quickly bump up against the quotas)

If this is the new normal: that's ok — but, it's helpful (for me, and probably other developers) to understand that this migration also comes with a change in expected resource consumption relative to the quotas.

[thebengeu]

Hey @andrewrosss, thanks for your detailed report! I wouldn't expect that for small tables with light usage, could you send your project reference ID to beng@supabase.io for us to investigate further please?

[thebengeu]

Upon investigation, the Disk IO consumption increase was indeed unexpected for a free plan project with light usage. We've fixed the underlying issue.

This wasn't related to the v2 migration, only appeared that it could be due to an unfortunate coincidence in timing: the project was newer so it was already on v2, its Disk IO consumption increase started the day before the v2 migration for a separate project.