Supabase Data API exposure changes on 30 October: grant tables explicitly

On 30 October 2026, Supabase made changes to the exposure of new tables in the public schema to the Data API. Previously, new tables were automatically reachable through the Data API. However, the new rule requires explicit Postgres grants before the Data API can access these tables. Existing tables remain unaffected and continue to use their current grants.

The change became applicable to all existing projects on 30 October 2026. Existing tables retain their current grants and remain accessible. This change primarily impacts tables created after the new default setting is implemented. Applications utilizing a direct Postgres connection, such as an ORM, psql, or a server with a connection string, are not affected.

To determine which tables the Data API can reach, a SQL query can be run to check for the presence of grants granted to the anon, authenticated, and service_role. If a table is missing from the query output, it will remain unreachable until appropriate grants are added. The Security Advisor will flag affected tables before the 30th, and owners or admins will receive email notifications.

Supabase recommends granting the minimum necessary privileges to each role. For anonymous clients, read-only access is recommended, while full access is granted to authenticated users, including signed-in users who have row-level security (RLS) applied. For server-side code using the service role, full access is recommended. It is advised not to grant write grants to the anon role unless the table is intended for anonymous writes.

Row-level security (RLS) should be enabled for all tables, including those created through the Supabase Dashboard or the SQL Editor. RLS determines which rows a given role can see, and it does not apply to functions. To ensure proper functionality, grants should be granted per table or opted in early. The dashboard automatically runs revoke statements at project creation, adopting the new behavior in existing projects.

Before the 30th, it is recommended to run the SQL query to identify the tables that the Data API can access. If a table is missing from the output, grants need to be added to make it reachable. The SQL statements for revoking default privileges can be found in the changelog, but it is recommended to compare them with the dashboard's statements before execution. These statements can be run on a staging project first and then applied to the production project.

After implementing the necessary grants, each role should be tested by calling the application's endpoints three times: with the anon key, a signed-in user's token, and the service role key from server code. Each request should return the expected data based on the role's privileges. If a 42501 error occurs, it indicates a missing grant, while an empty result from a table with expected rows suggests a policy that filters all rows.