Supabase will not start after latest update (to 1.203.0).

[Stokestack]

Describe the bug
After being informed by the CLI that an update was available, I did a brew update/upgrade. After that

supabase start

in my dev tree failed with lots of

00:01:51.050 [error] Postgrex.Protocol (#PID<0.4721.0>) failed to connect: ** (Postgrex.Error) FATAL 3D000 (invalid_catalog_name) database "_supabase" does not exist

Expected behavior
Supabase starting

Screenshots
If applicable, add screenshots to help explain your problem.

System information
Rerun the failing command with --create-ticket flag.

• Ticket ID: c52d2c1706f44c1a936ef52af8f67269
• Version of OS: Mac OS 15.0.1
• Version of CLI: 1.203.0
• Version of Docker: 27.3.1, build ce1223035a
• Versions of services: "Access token not provided."

Starting with
supabase start --ignore-health-check

appears to launch OK.

Probably a dupe of #2737 but I don't think that title reflects the severity of the problem.

[avallete]

It seems indeed duplicate.

Did you tried the suggestions on the issues ? Does the problem persist for you ?

Could you try supabase stop --no-backup followed by start? We switched to a new initialisation routine that's not compatible with local db state.

@ThingEngineer I started with analytics.enabled = false then did supabase db reset and that worked for me to create the missing database and schemas. Obviously this removes all your local data.

Another possibility to keep your local data would be to manually connect to the database container and manually run the migration:

CREATE DATABASE _supabase WITH OWNER postgres;
-- connect to _supabase database
\c _supabase
CREATE SCHEMA IF NOT EXISTS _analytics;
ALTER SCHEMA _analytics OWNER TO postgres;

CREATE SCHEMA IF NOT EXISTS _supavisor;
ALTER SCHEMA _supavisor OWNER TO postgres;

[Stokestack]

Fortunately I had not tried the DB reset yet, so I can try the tests you requested.

Restarting after
supabase stop --no-backup
failed, because I only had seed-data INSERTs in seed.sql, not table creation. So my custom DB tables were missing.

So I added table-drop & creation at the top of seed.sql. Now I'm getting

failed to send batch: ERROR: column "messageID" of relation "User_x_Message" does not exist (SQLSTATE 42703)

Which is wrong, because at the top of seed.sql I have:

CREATE TABLE "User_x_Message"
(
"senderID" UUID NOT NULL,
"recipientID" UUID NOT NULL,
"messageID" UUID NOT NULL,
"notifyRecipient" BOOL NOT NULL DEFAULT true,
"hideMediaMetadata" BOOL DEFAULT false,
downloaded BOOL DEFAULT false,
played BOOL DEFAULT false
);

So I gave up on seed data and removed the INSERT statements from seed.sql, and restarted. This time supabase started up without issue.

Then (in a database tool's terminal window), I executed the exact INSERT statements I'd previously had in seed.sql, and they worked without issue. So it appears we have a problem with seed.sql, in that table definitions must be included... but if they are, seed-data inserts fail.

[avallete]

Fortunately I had not tried the DB reset yet, so I can try the tests you requested.

Restarting after supabase stop --no-backup failed, because I only had seed-data INSERTs in seed.sql, not table creation. So my custom DB tables were missing.

So I added table-drop & creation at the top of seed.sql. Now I'm getting

failed to send batch: ERROR: column "messageID" of relation "User_x_Message" does not exist (SQLSTATE 42703)

Which is wrong, because at the top of seed.sql I have:

CREATE TABLE "User_x_Message"
(
"senderID" UUID NOT NULL,
"recipientID" UUID NOT NULL,
"messageID" UUID NOT NULL,
"notifyRecipient" BOOL NOT NULL DEFAULT true,
"hideMediaMetadata" BOOL DEFAULT false,
downloaded BOOL DEFAULT false,
played BOOL DEFAULT false
);

So I gave up on seed data and removed the INSERT statements from seed.sql, and restarted. This time supabase started up without issue.

Then (in a database tool's terminal window), I executed the exact INSERT statements I'd previously had in seed.sql, and they worked without issue. So it appears we have a problem with seed.sql, in that table definitions must be included... but if they are, seed-data inserts fail.

Indeed, seed.sql should not include any schema changes such as CREATE TABLE or DROP TABLE instructions, those should be scoped in migrations files and seed should be the place where the INSERT INTO lives.

[Stokestack]

Thanks for the confirmation.