Supabase Stops Honoring Your Pinned Extension Versions

Supabase will stop honoring explicit version numbers on Postgres extensions starting August 5, 2026. A statement like create extension pgvector version '0.7.0'; will still run without erroring, but the version clause is silently ignored, and the extension installs at its current default version instead, per a Supabase changelog announcement posted July 23.

---

What actually changed

The deprecation covers both create extension ... version '...' and alter extension ... update to '...'. After August 5, either statement succeeds, but Postgres logs a warning that only superusers can specify extension versions, and installs the default version on the project’s instance rather than whatever version was requested. The bare forms, create extension pgvector; or alter extension pgvector update;, are unaffected and are the drop-in replacement Supabase points teams toward.

Nothing changes for extensions already installed on a running database. The deprecation only touches new CREATE/ALTER statements that specify a version going forward, so migrations, seed scripts and infrastructure-as-code tooling that pin versions are the actual targets, not live projects sitting on an older build.

Supabase says this is step one of two. Right now, a pinned-version statement still succeeds, just with the version ignored and a warning logged, giving teams a window to find and fix any script still specifying one by grepping their Postgres logs for that warning. A future release, announced separately in advance, will turn the same statement into a hard error.

Why Supabase is doing this

The stated rationale is security, not simplification: any database role that could specify an extension version could also downgrade one, and a downgrade can reintroduce a vulnerability the default version already patched. Restricting version selection to Supabase’s own platform operations closes that path.

What to do about it

Search migrations, seed scripts and any tooling that manages extensions for VERSION '...' or UPDATE TO '...' clauses and drop them — the bare CREATE EXTENSION and ALTER EXTENSION ... UPDATE forms work today and won’t break when the hard error lands later. Teams that provision extensions through Terraform, a custom migration runner, or a dbdev-style package manager should check those tools specifically, since a pinned version buried in generated SQL is easy to miss until the warning starts showing up in production logs, or until the follow-up release turns it into a failed deploy.

---

Key Takeaways

• Starting August 5, 2026, Supabase ignores explicit version numbers in CREATE EXTENSION and ALTER EXTENSION ... UPDATE TO statements and installs the default version instead, logging a warning.
• Existing installations on running databases are unaffected; only new statements that specify a version are in scope.
• The rationale is security: pinning let any role install or downgrade to an extension version with known vulnerabilities.
• A future release will turn the same statements into hard errors instead of warnings — this is a grace period, not the final state.
• Fix: drop VERSION '...' and UPDATE TO '...' clauses from migrations and provisioning tooling now, rather than waiting for the hard error.

---

The take

Closing a privilege-escalation path is a reasonable thing for a managed Postgres platform to do, and giving teams a warning-only window before the hard error is a fairer rollout than Supabase’s own connection-logging change pulled off weeks earlier, when existing projects got auto-migrated with no notice at all. But the fix is still arriving as a changelog line two weeks before it takes effect, for a feature (version pinning) that plenty of teams reach for specifically to keep a known-good extension version through a Postgres upgrade. If your migrations or infrastructure code pin an extension version anywhere, that pin already stopped doing what you think it does the moment August 5 arrives. Check now, not when the warning shows up mid-incident.