Supabase Requires Explicit Permission Grants for New Tables Starting May 30.

Supabase is changing how new projects handle database permissions. Starting May 30, 2026, tables created in the public schema will no longer be automatically exposed to the Data API. Instead, developers must explicitly grant permissions to each role, either through the dashboard or via SQL.

The shift is part of Supabase's broader push toward declarative infrastructure code. By requiring explicit Postgres grants, the platform aims to make permission models reviewable, diffable, and greppable. The change only affects new projects created after the cutoff date; existing projects will continue to work as before.

"Explicit Postgres grants are reviewable, diffable, and greppable," the company announced on LinkedIn. "They also give you per-role control: anon and authenticated need different privileges in most schemas, and an explicit grant makes that difference visible in your migrations."

Currently, when developers create a table in the public schema on Supabase, the platform automatically grants SELECT, INSERT, UPDATE, and DELETE permissions to both the anon and authenticated roles. This means any authenticated user can immediately query, modify, or delete data in newly created tables unless developers remember to revoke those permissions.

The new behavior flips this default. Tables will start locked down, and developers must consciously decide which roles get which permissions. For example, granting SELECT access to anon while restricting INSERT and UPDATE to authenticated now requires an explicit SQL statement or dashboard action:

GRANT SELECT ON public.users TO anon;
GRANT ALL ON public.users TO authenticated;

This approach makes access control visible in migration files and version control, reducing the risk of unintentional data exposure.

Automatic permission grants made Supabase fast to prototype with, but they introduced security risks in production. Developers often forgot to lock down tables after creating them, leaving sensitive data accessible to unauthenticated users or overly permissive to authenticated ones. Explicit grants force developers to think about access control upfront.

The new default also aligns better with migration-based workflows. When permissions are declared in SQL migrations, teams can review changes in pull requests, track permission history in Git, and enforce consistent access policies across environments. This mirrors best practices from infrastructure-as-code tools like Terraform and Vercel, which emphasize explicit configuration over implicit behavior.

Supabase has been steadily moving in this direction. In early May, the platform made dashboard branching the default for all projects, enabling teams to test schema changes in isolated environments before merging to production. Explicit permission grants fit naturally into this workflow, where every database change is deliberate and auditable.

Existing projects are unaffected. The change only applies to projects created on or after May 30, 2026. Developers working on older projects can opt into the new behavior manually by revoking default grants and adding explicit ones in their migration scripts.

For teams starting new projects after the cutoff, the initial workflow changes slightly. After creating a table via the Supabase dashboard or a migration, developers will need to grant permissions explicitly. The dashboard will surface this requirement with prompts and tooling to simplify the process, though SQL remains the canonical way to manage grants.

Developers using Supabase's server package or building with tools like Bubble, Xano, or Buildship should review their table creation workflows to ensure permissions are granted correctly after the update takes effect.

This update reflects a broader industry shift toward explicit infrastructure management. Platforms like Supabase, Railway, and Neon are moving away from magic defaults that prioritize speed over clarity. For production applications, the trade-off makes sense: a few extra lines of SQL upfront prevent costly security incidents later.

Supabase's move toward declarative permissions also positions the platform better for enterprise adoption, where audit trails and compliance requirements demand clear, version-controlled access policies. Combined with recent updates like the ChatGPT integration and ISO 27001 certification, the platform is signaling that it can scale beyond prototyping into regulated, production-grade environments.

For developers building on Supabase, the takeaway is straightforward: if you're starting a new project after May 30, plan to grant permissions explicitly. The change adds a small amount of upfront work, but it makes your application's security model visible and auditable from day one.