Need exact supautils build/runtime identity for PostgreSQL 17.4 project

[nicoavayu]

Hi,

I’m preparing a controlled database migration on a Supabase project running PostgreSQL 17.4.

Before executing anything in Production, I’m trying to reproduce the Production runtime locally as faithfully as possible.

From READ-ONLY inspection of Production and local testing, I confirmed:

• Production behavior is consistent with supautils >= 3.3.0.
• The public Supabase Postgres 17.4 image I can reproduce locally uses supautils 2.9.4.
• Production exposes:
  • supautils.disable_program
  • supautils.hint_roles
  • supautils.restrict_extension_versions
• Production uses supautils.policy_grants to allow postgres to manage policies on storage.objects while storage.objects remains owned by supabase_storage_admin.
• I reproduced the policy_grants behavior locally, but I cannot reproduce the full Production supautils runtime with the public PostgreSQL 17.4 image.

I’m trying to identify:

1. The exact supautils version/build used on hosted PostgreSQL 17.4 projects.
2. Whether hosted Supabase uses provider-specific patches or compile flags.
3. Whether there is a public image/tag/digest that reproduces the same PostgreSQL 17.4 + supautils runtime locally.
4. Whether supautils can be upgraded independently from the PostgreSQL engine on hosted projects.

I’m not asking for credentials or access to provider internals beyond runtime/build identity.

I already have a support ticket open: SU-463460.

Any guidance from the Supabase team would be greatly appreciated.

[amasen02]

Reproducing Hosted PostgreSQL 17.4 & supautils Locally

Here is a breakdown of how Supabase packages supautils for PostgreSQL 17.4, the exact public Docker images that match hosted production, and how extension binaries are managed.

---

1. Build Pipeline & Public Image Matching Production

Hosted Supabase does not use closed-source forks of Postgres; all production images are built via Nix flakes in the public supabase/postgres repository.

The mismatch you encountered with local testing having supautils 2.9.4 usually happens when running an older cached image from Docker Hub (supabase/postgres:17.4...) or a local build rather than the official AWS ECR mirror used by the Supabase CLI and cloud fleet.

To pull the exact PostgreSQL 17.4 production image containing supautils >= 3.3.0 (with supautils.policy_grants support):

# Pull the pinned production image from Supabase's public ECR repository
docker pull public.ecr.aws/supabase/postgres:17.4.1.0

To run this locally with the exact production shared_preload_libraries configuration:

docker run -d \
  --name supabase-pg17 \
  -e POSTGRES_PASSWORD=postgres \
  -p 5432:5432 \
  public.ecr.aws/supabase/postgres:17.4.1.0 \
  postgres \
  -c shared_preload_libraries="supautils,pg_stat_statements" \
  -c supautils.policy_grants="storage.objects=postgres"

---

2. Identifying the Exact Version & Commit In-Database

You can verify the exact build identity and extension commit on your hosted project by running these read-only queries:

-- 1. Check the installed & available extension version
SELECT name, default_version, installed_version, comment 
FROM pg_available_extensions 
WHERE name = 'supautils';

-- 2. Inspect active GUCs exposed by the loaded supautils library
SELECT name, setting, unit, short_desc 
FROM pg_settings 
WHERE name LIKE 'supautils.%';

-- 3. Verify PostgreSQL server compile stamp
SELECT version();

---

3. Answers to Your Specific Questions

1. The exact supautils version/build used on hosted PG 17.4

Hosted PG 17.4 deploys supautils pinned from the 3.3.x branch (specifically commit snapshots supporting policy_grants and hint_roles). The exact Git revision is tracked in flake.lock in the supabase/postgres repository under the supautils input.

2. Are there provider-specific patches or compile flags?

No closed-source patches are applied. All patches used in production builds are stored in supabase/postgres/patches/ and are publicly reproducible. The primary build difference between a plain community image and the hosted runtime is the Nix environment configuration (nix build .#packages.x86_64-linux.postgres_17).

3. Public image tag/digest to reproduce locally

Use public.ecr.aws/supabase/postgres:17.4.1.0 (or check the tag defined in your local supabase CLI via supabase --version). This image includes the full suite of compiled .so binaries matching cloud production.

4. Can supautils be upgraded independently on hosted projects?

No. Because supautils is loaded via shared_preload_libraries before user connections are accepted, supautils.so is part of the root filesystem image. It cannot be upgraded via ALTER EXTENSION independently of the underlying PostgreSQL container image. New supautils versions roll out when Supabase releases image updates, which appear as available upgrades in your project's Settings > Infrastructure > Database Upgrade.