Verdict
On release day, Supabase CLI 3.0.0 started the same local stack as 2.122.1, and row-level security behaved identically. What changed is the targeting: db push and gen types with no flags now run against the local stack and print Target: local stack, where v2 failed in the same unlinked project. --linked still works but warns, db remote commit is gone, an old [inbucket] section in config.toml now stops every command, and an invalid SUPABASE_* variable is rejected by name.
Tested on
- Supabase CLI
- 3.0.0 (released November 2, 2026) and 2.122.1, from npm
- supabase-js
- 2.118.0
- Node
- 24.22.1
- OS
- Ubuntu on GitHub Actions, Docker 29.4.2
✓ Last re-run on GitHub Actions · see the run · all repros
Contents
Supabase released CLI 3.0.0 on November 2, a major version with a long list of breaking changes in its release notes. I ran the same steps on 3.0.0 and on the last 2.x (2.122.1), in fresh projects with a local stack in Docker, the same day. Nothing in this test touched a hosted project.
What changed, side by side
| Same step | CLI 2.122.1 | CLI 3.0.0 |
|---|---|---|
supabase init + supabase start |
local stack starts | local stack starts, same API URL http://127.0.0.1:54321 |
supabase db push, no flags, project not linked |
fails with an error (v2’s default target was the linked project) | runs against the local stack: Target: local stack (127.0.0.1:54322), Local database is up to date. |
supabase gen types --lang typescript, no flags |
fails with an error | generates from the local database (prints Target: local stack) |
supabase db push --linked |
Cannot find project ref. Have you run supabase link? |
same, plus Warning: --linked is deprecated and will be removed in v4. Use --remote instead |
supabase db remote commit |
Command "commit" is deprecated and will be removed in v3 |
removed: supabase db remote commit was removed. Use supabase db pull --remote instead. |
[inbucket] section in config.toml |
a deprecation warning | every command fails: [inbucket] in supabase/config.toml is no longer supported. Use [local_smtp] instead. |
SUPABASE_STUDIO_PORT=abc |
Invalid config for studio.port: cannot parse "abc" as a port |
Invalid SUPABASE_STUDIO_PORT="abc" (sets studio.port): expected a port (0-65535). |
The big one is the first change. In v2, db push with no flags went to the linked project (that’s what the release notes change), and in my unlinked v2 project it failed. In v3 it means your local stack. A script or habit that ran supabase db push to deploy migrations to production now pushes them to localhost instead, and reports success. Check the Target: line v3 prints on stderr; it says exactly where the command went.
Fix your scripts
Deploying migrations or generating types from a hosted project: add --remote.
supabase db push --remote
supabase gen types --lang typescript --remote--linked, --project-ref and --db-url still work in 3.0.0 and only warn, but the warning says they go in v4. Switch them to --remote now, while the old form still runs.
db remote commit: use supabase db pull --remote, as the error says.
An old config.toml with [inbucket]: rename the section to [local_smtp]. Until you do, v3 refuses to run commands in that project: supabase status failed with the message above.
What I couldn’t test: hosted projects
The other half of the release is about hosted projects, and I didn’t run any command against one. From the release notes, not tested here:
- Every command that changes a hosted project now asks first, the default answer is No, and unattended runs (CI, JSON output, agents) fail with
HostedMutationConsentRequiredunless you pass--yes. - A
ypiped on stdin no longer confirms, andSUPABASE_YESin a.envfile no longer counts. - Flags and shell environment variables now override
config.toml, including[remotes.*]blocks. - Without
project_idinconfig.toml, local containers are named after the project folder; the notes say to runsupabase stopbefore upgrading. (A freshsupabase initon 3.0.0 still wrote aproject_id.)
If your CI pipeline runs supabase db push or functions deploy against a hosted project, it’s the --yes change that will stop it. The official v2 to v3 migration guide covers each of these.
What didn’t change: row-level security
I re-ran the main cases from new row violates row-level security policy (42501) against both local stacks, as the anon role:
| Policies on the table | insert() |
insert().select() |
|---|---|---|
| none (RLS on) | 42501 new row violates row-level security policy |
42501 |
| INSERT only | works | 42501: returning the row needs a SELECT policy too |
| INSERT and SELECT | works | works, returns the row |
Identical on 2.122.1 and 3.0.0. The upgrade doesn’t touch your policies; it changes which database the CLI talks to.
How this was tested
November 2, 2026, the day 3.0.0 was released (12:18 UTC). Two fresh projects on GitHub Actions ubuntu-latest (Node 24.22.1, Docker 29.4.2), one with supabase@3 (3.0.0) and one with supabase@2 (2.122.1) from npm, each running supabase init and supabase start, then the same table, policies and supabase-js 2.118.0 calls, the same CLI commands, and the same edited config.toml. No project was linked and no hosted project was used. The script is public, and so are both runs with their full logs: CLI 3.0.0 and CLI 2.122.1, finished at 17:00 UTC.
— N.K., end of entry No.095