Forthcoming Postgres 17 Release Notes

[samrose]

The upcoming release of Supabase Platform will use Postgres 17. The Postgres 17 bundle will no longer include the following Postgres extensions:

• timescaledb
• plv8
• plls
• plcoffee
• pgjwt

Existing projects will NOT be immediately impacted - the extensions will continue to be supported on Supabase Postgres 15, until the Supabase Platform “end of life” of Postgres 15 in approximately 1 year (May 2026). However, the extensions will not receive further updates and fixes. Existing projects will need to drop the extensions before they can upgrade to Postgres 17.

This decision to deprecate these extensions was not made lightly, however these extensions are more complex than “standard” Postgres extensions and require additional support/testing that did not match the usage we see on the platform.

To address the capability gaps left by deprecating plv8 and timescaledb, we plan to include the pg_partman extension in a future Postgres 17 release and will provide documentation to help migrate Timescale hypertables to native Postgres partitioning at that time. For plv8 we recommend porting the logic to Edge Functions, which offer greater scalability and flexibility. These changes are part of our ongoing efforts to streamline our platform, reduce operational complexity, and ensure long-term support for features that align closely with our user base.

If you have additional use-cases for these deprecated extensions, please reach out to us and our Success team will work with you to find a solution.

[GaryAustin1]

You might consider marking these somehow in the current dashboards as deprecated or similar to reduce new use of them.
The dashboard extensions page still allows installs and has no mention of planned deprecation.

[Wonderful27]

The upcoming release of Supabase Platform will use Postgres 17. The Postgres 17 bundle will no longer include the following Postgres extensions:

• timescaledb

• plv8

• plls

• plcoffee

• pgjwt

Existing projects will NOT be immediately impacted - the extensions will continue to be supported on Supabase Postgres 15, until the Supabase Platform “end of life” of Postgres 15 in approximately 1 year (May 2026). However, the extensions will not receive further updates and fixes. Existing projects will need to drop the extensions before they can upgrade to Postgres 17.

This decision to deprecate these extensions was not made lightly, however these extensions are more complex than “standard” Postgres extensions and require additional support/testing that did not match the usage we see on the platform.

To address the capability gaps left by deprecating plv8 and timescaledb, we plan to include the pg_partman extension in a future Postgres 17 release and will provide documentation to help migrate Timescale hypertables to native Postgres partitioning at that time. For plv8 we recommend porting the logic to Edge Functions, which offer greater scalability and flexibility. These changes are part of our ongoing efforts to streamline our platform, reduce operational complexity, and ensure long-term support for features that align closely with our user base.

If you have additional use-cases for these deprecated extensions, please reach out to us and our Success team will work with you to find a solution.

[eeston]

Is there an easy way to see where/why extensions were installed?

I'm trying to figure out why I have pgjwt installed. I can't see any reference to it in my backend repo or postgres migrations so I can only assume it came preinstalled when I first setup my supabase instance?

[eeston]

Thanks for the prompt reply @samrose 🙌

[riderx]

@samrose can we remove it in current v15 without issue ?

[thisislvca]

Yeah I removed it without any issues

[ronlobo]

As pgjwt relies on pgcrypto, is it safe to assume that pgcrypto can be removed as well? Unless ofc it's being used in some different application context. Thanks!

[soedirgo]

@ronlobo yes you can remove it. Do use drop extension pgcrypto instead of drop extension pgcrypto cascade in case of accidental usage, but there should be no usage from Supabase-managed schemas.

[riderx]

Thanks for removing timescaledb, they didn't deserve to been in an open-source project with their bad license.

[jandillmann]

Would it be possible to support a supabase start -x db to start all containers except the database so I can run my own container image instead?

[silentworks]

If you want to do that then you use the docker compose setup and not the CLI. The CLI is meant to use the supabase/postgres image to keep a consistent enough environment between local and production.

[dule-kitemetric]

@encima
Currently I use the TimescaleDB and create its hypertable to simplify the partition process (which i have to put more works if setting up from scratch) and to improve query performance (as it advertised). I don't use much advance features that TimescaleDB provides.
If you're removing TimescaleDB, I wish you could make a good blog/documentation that guides & explains in details what i should do to migrate from my existing PostgreSQL database (self-hosted Supabase) + timescaledb to use the pg_partman (as you mentioned).

[encima]

pg_partman is expected to be available at the end of Oct and we will have a blog post along with it!

The postgres image is open source but we don't currently have a guide for it. Plugging into an external database is harder as it needs the same roles, extensions and migrations applied. Running locally you have superuser access and you can build a custom image from the supabase/postgres repo

[1411381]

When is pg_partman scheduled for release?

[riderx]

I tried to spin locally 17.4.1.037 and it didn't boot, I don't recommend trying upgrading even if the dashboard in Supabase proposes it

[silentworks]

The issue you are facing is related to the CLI and not 17.4.1.x itself as this also happens in 15.8.1.94. You can see more on this here supabase/cli#3632, the Supabase team is looking into the issue.

[riderx]

fixed ! we just need to use 17.4.1.038 or 15.8.1.95 thanks for linking it !

[khera]

One thing that would really help is if the CLI had an "upgrade" option similar to the dashboard. I know I can edit the Postgres-version file, but that doesn't update the versions of the other images. The only way right now to see what those versions are is to do an upgrade in the cloud and then link locally. I can then test in the safety of my local environment, which by definition is allowed to break and be wiped.

[silentworks]

Not exactly what you are after but you can set major_version = 17 in your config.toml for it to use Postgres 17.

[cpursley]

Any ETA for the v17 drop?

[silentworks]

It's being rolled out currently to new projects. If you create a new project it's likely to have v17.

[riderx]

I just upgraded my prod db to it, just go to the infrastructure tab

[jandillmann]

we plan to include the pg_partman extension in a future Postgres 17 release and will provide documentation to help migrate Timescale hypertables to native Postgres partitioning at that time

Will there be a replacement for the hyperfunctions?

[encima]

Nothing built into pg_partman or postgres, no.
Which functions are you using? We can see if there are ways to include a subset of them (or alternatives)

[jandillmann]

We're building a heavily time-series based product, so the removal of TimeScale is very unfortunate.

The functions we're currently using the most are time_bucket and time_bucket_gapfill with locf as well as state tracking and continuous aggregates.

[quick691fr]

Same here, how to replace those hypertable time_bucket queries ...

[sweigert]

We are using time_bucket, too but I think date_bin is a viable postgres-native alternative. I haven't tried it, though as pg_partman is still not available.

I'm wondering, though how you ever used time_bucket_gapfill and continuous_aggregate since they are not part of the Apache license or are they?

[jandillmann]

Didn't use it on Supabase, but on our current self-hosted TimescaleDB instance. Would have loved to move everything over to Supabase…

[tvogel]

I am actively using pgjwt to implement authentication for another service. Any suggestion what to replace it with? I liked having that key component directly in the database logic as opposed to running on the edge.

[Sanires]

Same here - waiting for the 17. release before removing it

[soedirgo]

pgjwt is a SQL-only extension so you can create the extension functions in your own schema and use them the same way

[tvogel]

pgjwt is a SQL-only extension so you can create the extension functions in your own schema and use them the same way

Ah, good point. Thanks for the clarification! Is there new infrastructure that supabase will use for JWT creation (for example supporting asymmetric encryption) that I could consider switching to?

[soedirgo]

@tvogel nothing in the roadmap; you could always build on pgjwt functions, but if you need anything sophisticated it's probably best to do it on the application side.

[skamensky]

What is the reasoning for dropping support for plv8?
I have a complex function that generates views based on table metadata. This will be very difficult to maintain in plpgsql.
Another place I use plv8 is when I generate full text search columns ( I dynamically scan which columns are sensible to include in the fts column and create a GIN index for those values). This is another function that would be a maintenance and debugging burden to maintain in plpgsql.

And edge functions aren't an option since both of these use cases must be run idempotently and atomically.

[tvogel]

I am also not too happy about dropping plv8 because I use it to generate asymmetrically signed JWT for a third-party service to authenticate against and this is something, I prefer to handle on the database in contrast to on the edge. I hope that the new token infrastructure where asymmetric encryption was mentioned might offer something, I will be able to use. But I probably shouldn't hold my breath and will workaround it with an edge function.

[lauri865]

Supabase has been shiling plv8 for a while, dropping this now is extremely disappointing... we use it to share RBAC logic between RLS and backend. Migrating this will be an insane headache. Might even warrant migrating away from Supabase altogether.

[encima]

Hey @lauri865
Sorry to hear that, we have a blog post coming to help with that migration and moving the logic but feel free to email success@supabase.io to help you out!

[pkit]

@lauri865 use Neon, it supports plv8 quite well.

[dule-kitemetric]

Hi @samrose ,
How about the self-hosted Supabase? It it affected?
Can I use the combo TimescaleDB + Self-hosted Supabase with PostgreSQL 17?

[encima]

The image for postgres contains all the extensions so Timesacle will not be in that image. You could use your own postgres image but this is not fully supported

[eeston]

Upgraded this morning. Total breeze, no issues. Took 6mins 👍

[nickdichev]

Is pg_partman still expected at the end of october?

[samrose]

@nickdichev we do not have an exact date yet, but it's in progress and going to land as soon as we can.

[AMoldskred]

@samrose Any updates here? Would love to see this soon.

[franmontiel]

@samrose is pg_partman expected to be included prior Postgre15 end of life?

[foerster]

Edge functions are not at all comparable to plv8. I have a lot of calculations and things that need to occur at the time a match completes in a tournament... edge function is not a good way to do it at all.

[riderx]

and this cannot be done in SQL ?

[pkit]

Theoretically SQL with recursive CTEs is Turing complete. But practically writing business logic twice: once in JS/TS on the server/client and once in SQL is wasteful.
Unless you want to write your whole server in SQL...

[foerster]

It’ll suck. I have to iterate all matches and calculate match statistics, placement and advancement points, shortest pin and tech fall times…. That’ll be horrific in sql. Other ones I do match advancement in brackets… all much harder in sql. On Dec 22, 2025, at 9:19 AM, Martin DONADIEU ***@***.***> wrote:  and this cannot be done in SQL ? — Reply to this email directly, view it on GitHub<#35851 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AACTXQEXMLM5TBUT6YLCZUT4C74V7AVCNFSM6AAAAAB5WXJ452VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMZRHA3DENI>. You are receiving this because you commented.Message ID: ***@***.***> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

[tvogel]

It’ll suck. I have to iterate all matches and calculate match statistics, placement and advancement points, shortest pin and tech fall times…. That’ll be horrific in sql.

Really? I mean, SQL is particularly for correlating and processing a lot of data in a performant and structured way. I don't know your level of SQL wizardry but would look at common table expressions (CTEs). I love them and it's just the right thing to do to represent your business logic in SQL if you can.