Does the 2026-10-30 auto_expose_new_tables deprecation also revoke default privileges on existing cloud projects?

[memobotero-1970]

Context

Our production project (created a while back) has default ACL rules on the public schema
that auto-expose new objects to the Data API roles. Running:

SELECT defaclrole::regrole, defaclnamespace::regnamespace, defaclobjtype, defaclacl
FROM pg_default_acl;

on production returns two rules on public, owned by postgres and supabase_admin, both
granting arwdDxtm to anon, authenticated and service_role for relations.

The practical effect, measured today: all 24 tables in public return true for
has_table_privilege('anon', oid, 'SELECT'). A fresh local stack built from the exact same
migrations returns false for all 24 — no default ACL rules on public there.

To be clear about what we already have in place: RLS is enabled AND forced on all 24 tables
in production, so this is not a "you forgot to enable RLS" situation. What we are looking at
is the privilege layer underneath it, and the fact that it differs between an old cloud
project and a fresh environment built from identical migrations.

The CLI config documents the deprecation like this:

# Controls whether new tables, views, sequences and functions created in the `public`
# schema by `postgres` are reachable through the Data API roles (`anon`, `authenticated`,
# `service_role`) without explicit GRANTs. When unset, new entities are NOT auto-exposed,
# matching the new cloud default. Set to `true` to keep the legacy behaviour of
# auto-exposing new entities; this is deprecated and the field is removed on 2026-10-30
# once the always-revoked behaviour is permanent.

Questions

1. On 2026-10-30, does Supabase remove or revoke these pg_default_acl rows on existing
   cloud projects, or does that date only remove the auto_expose_new_tables field from the
   CLI config, leaving already-created databases with their current default privileges
   unchanged?

2. If existing projects are not touched, is it safe and supported for us to run
   ALTER DEFAULT PRIVILEGES IN SCHEMA public ... REVOKE ... ourselves against the two
   owning roles? Specifically, would revoking the supabase_admin rule interfere with
   anything the platform manages on our behalf?

3. Is there any announcement or migration note for existing projects that we should be
   following?

Thanks — happy to provide anything else that helps.

[wonjangcloud9]

Two different things are attached to 2026-10-30, and the config comment you quoted is about the one that was cancelled. Separating them answers all three questions.

• The platform rollout is still on. Breaking Change: Tables not exposed to Data and GraphQL API automatically is the announcement, and it says: "On October 30, 2026 the setting will be applied to all existing projects."
• The CLI field removal was called off. The # ...the field is removed on 2026-10-30 wording you quoted came from cli#5239's tri-state rollout plan. cli#6337 (merged 2026-08-26) reversed it, because the CLI had flipped its local default "anticipating a cloud default change that never landed," and it removed "the deprecation warning and the 2026-10-30 removal narrative ... since their premise collapsed." auto_expose_new_tables is not going away. That sentence survives only in the legacy apps/cli-go template and struct comment, which How do I change my email address? #6337 did not clean up.

Q1 — what happens to your project on 2026-10-30

The rollout changes the default-privilege layer so new objects in public are no longer auto-exposed. Your existing 24 tables are not touched.

This was asked directly in the announcement thread and confirmed by Supabase:

Are existing tables on existing projects guaranteed to retain their current grants and will they never be silently revoked by the October 30 rollout?

— @steve-chavez: Both are correct.

The mechanism is why: ALTER DEFAULT PRIVILEGES only applies at CREATE time, so the grants your 24 tables received are materialized in each table's own ACL. Removing the pg_default_acl rows cannot retroactively strip them. has_table_privilege('anon', oid, 'SELECT') will still return true for all 24 on 2026-10-31; only the 25th table behaves differently.

So if least privilege on the existing tables is the goal, October 30 will not do it for you — that needs explicit REVOKE statements in your migrations.

Q2 — revoking it yourself

Split by owning role, which decides both permission and support:

• The postgres-owned rule is yours to change, and doing so is supported. It is exactly what the project-creation toggle does, and what the CLI runs for auto_expose_new_tables = false. Running it now just moves your project to its post-October state early:

  alter default privileges for role postgres in schema public
    revoke select, insert, update, delete on tables from anon, authenticated, service_role;
  
  alter default privileges for role postgres in schema public
    revoke usage, select on sequences from anon, authenticated, service_role;

• The supabase_admin-owned rule is not, and you should leave it. Postgres only lets you alter default privileges for a role you are a member of, so it fails with 42501 — see #50095, where someone hit exactly that. The platform side is what the October rollout handles on your behalf.

Nothing the platform manages depends on the postgres-owned rule, so revoking it does not interfere. What it does affect is your own future migrations: from that point on, every new table you want reachable over the Data API needs an explicit GRANT beside it.

Q3 — what to follow

Discussion #45329 is the announcement and carries the three dates; the thread itself has become the de-facto migration note, including @steve-chavez's confirmation above. Security Advisor flags affected tables, and Data API settings in the dashboard lists what is currently exposed.

Why local and production disagree

Worth naming, since it is the measurement that prompted the question: your fresh local stack isn't drifting from your migrations — it is already sitting in the post-October state.

The Go shell's ApplyApiPrivileges treats unset as "revoke":

if utils.Config.Api.AutoExposeNewTables != nil && *utils.Config.Api.AutoExposeNewTables {
    return nil
}
// ...otherwise run RevokeDefaultDataApiPrivilegesSql

while the current config schema documents unset as auto-expose, matching cloud. With the flag unset you can land on either behaviour depending on which shell bootstraps the stack, which is what #6337 was fixing.

Stop relying on the implicit default and pin it. Given you want least privilege anyway, the version that survives October unchanged is:

[api]
auto_expose_new_tables = false

(the local equivalent of the cloud toggle, added in CLI v2.102.0), plus explicit GRANT statements in your migrations for the tables that genuinely need Data API access — so db reset replays them and local and production describe the same surface.

[cekuu35]

A related footgun to the one-way deprecation: because old projects keep the auto_expose default while the new default flips for fresh projects, any client built against the OLD default silently re-exposes new tables on every schema change unless it explicitly opts in to the new behavior at connection time. The migration-safe move is to make exposure explicit in your client/DDL tooling now, rather than relying on whichever default was active when the project was created - that way the flip on 2026-10-30 won't change what an old project actually exposes.

[wonjangcloud9]

The conclusion is right, but the mechanism in the first half is not, and the difference matters for anyone planning around 2026-10-30.

There is no client-side opt-in here. auto_expose_new_tables is not a connection parameter and clients do not select an exposure mode when they connect — it describes rows in pg_default_acl, which Postgres applies at CREATE time, by the role creating the object. A client library has no part in it, so "a client built against the old default" cannot re-expose anything.

It is also not "on every schema change". Default privileges attach to objects as they are created. A migration that alters an existing table grants nothing new; a migration that creates a table gets whatever default ACL is in force for the creating role at that moment.

Where this lands for the original question, and it is the part worth keeping: since the grants are materialised into each object's own ACL when it is created, nothing retroactive happens on 2026-10-30, and @steve-chavez confirmed that existing tables on existing projects keep their grants and will not be silently revoked. What changes is the default that new objects inherit after that date.

So the advice to make exposure explicit is sound — but the reason is not that a client might re-expose something. It is that relying on any implicit default leaves the surface defined by when the project happened to be created. Explicit GRANT statements beside the tables that need them, in the migrations, make the Data API surface reviewable in the diff and identical before and after the rollout.

[cekuu35]

)
Short answer: No, it only affects NEW tables created after the change.

        The `auto_expose_new_tables` setting controls whether **newly created** tables in the `public` schema get default grants to `anon` + `authenticated` roles. The deprecation (Oct 30, 2026) means Supabase will stop auto-granting these privileges on new tables.

        **What it does NOT do:**
        - Does NOT revoke existing grants on current tables
        - Does NOT change RLS policies
        - Does NOT affect `GRANT ... ON ALL TABLES IN SCHEMA public` you've run manually

        **What you should do before Oct 30:**
        1. **Audit current grants** (run in SQL Editor):
        ```sql
        SELECT grantee, table_name, privilege_type
        FROM information_schema.table_privileges
        WHERE table_schema = 'public' AND grantee IN ('anon', 'authenticated');
        ```

        2. **Explicitly grant only what you need** for each table:
        ```sql
        REVOKE ALL ON your_table FROM anon, authenticated;
        GRANT SELECT ON your_table TO authenticated; -- or anon if truly public
        ```

        3. **Enable RLS everywhere** — grants become irrelevant when RLS is enabled with proper policies.

        **Migration path**: After Oct 30, new tables will have NO default grants. You'll need explicit `GRANT` in your migrations (which is actually better — explicit > implicit).

        Free audit script: https://github.com/cekuu35/supabase-rls-leak-demo