Seeding script `supabase/seed.sql` emits syntax error (PGSQL 42601) with `COPY ... FROM STDIN;`

[od-vennre]

Bug report

• [x] I confirm this is a bug with Supabase, not with my own application.
• [x] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

The Supabase CLI fails to properly process COPY ... FROM STDIN; syntax in the seed.sql file during database seeding with supabase reset db.

When using the PostgreSQL COPY command with FROM STDIN syntax for bulk data insertion in the seed file, the CLI reports a syntax error. This same seeding file works perfectly when executed directly with psql.

Error message:

Seeding data from supabase/seed.sql...
failed to send batch: ERROR: syntax error at or near "00000000" (SQLSTATE 42601)

The error occurs at the first data row after a COPY statement:

COPY auth.users (instance_id, id, aud, ...) FROM stdin;
00000000-0000-0000-0000-000000000000	...  <-- Error occurs here
\.

To Reproduce

1. Create a supabase/seed.sql file containing COPY ... FROM STDIN; statements
2. Run supabase reset db
3. Observe the syntax error

The seed file structure I'm using:

ALTER TABLE xxx.xxx DISABLE TRIGGER USER;
ALTER TABLE xxx.xxx DISABLE TRIGGER USER;
ALTER TABLE xxx.xxx DISABLE TRIGGER USER;

BEGIN;

SET CONSTRAINTS ALL DEFERRED;

-- restore data
COPY xxx.xxx (...) FROM STDIN;
...
\.

COPY xxx.xxx (...) FROM STDIN;
...
\.

COPY xxx.xxx (...) FROM STDIN;
...
\.

-- restore sequence state
SELECT pg_catalog.setval('xxx.xxx', x, true);
SELECT pg_catalog.setval('xxx.xxx', x, true);
SELECT pg_catalog.setval('xxx.xxx', x, true);

END;

ALTER TABLE xxx.xxx ENABLE TRIGGER USER;
ALTER TABLE xxx.xxx ENABLE TRIGGER USER;
ALTER TABLE xxx.xxx ENABLE TRIGGER USER;

Expected behavior

The supabase reset db command should be able to successfully process COPY ... FROM STDIN; syntax in the seed file, just as the direct psql command does:

psql -h localhost -p 54622 -U postgres -d postgres -f seed.sql

The direct psql command works perfectly, generating the expected output with successful data insertion.

Workaround attempted

As a temporary workaround, I'm manually running the seed file after reset:

supabase db reset --no-seed
psql -h localhost -p 54622 -U postgres -d postgres -f supabase/seed.sql

However, this defeats the purpose of having a streamlined reset process with automatic seeding.

System information

• OS: macOS 15.3.1 24D70 arm64
• Browser: Chrome
• Version of supabase-js: 2.49.4
• Version of Node.js: 22.14.0

neofetch --stdout

OS: macOS 15.3.1 24D70 arm64 Host: Mac14,9 Kernel: 24.3.0 Uptime: 20 days, 6 hours, 44 mins Packages: 372 (brew) Shell: zsh 5.9 Resolution: 1512x982 DE: Aqua WM: Quartz Compositor WM Theme: Blue (Light) Terminal: Apple_Terminal Terminal Font: FiraCodeNerdFontCompleteM-Retina CPU: Apple M2 Pro GPU: Apple M2 Pro Memory: 3197MiB / 16384MiB

Additional context

I am running the Supabase local dev environment using a remote docker context (i.e. DOCKER_HOST=ssh://...), with port-forwarding over the entire 54320-54329 range using autossh as a launchd service on macOS.

I believe this setup is not contributing to the bug since the same seed file works perfectly when executed directly with psql.

It appears the Supabase CLI is processing the seed file differently than psql does, specifically with how it handles the COPY ... FROM STDIN; syntax and the data rows that follow.

[Ivan-developer0]

Short Solution:

The Supabase CLI currently does not support COPY ... FROM STDIN; syntax in seed files, which causes syntax errors during supabase db reset.

Workaround:
Run reset without seeding, then manually seed using psql:

supabase db reset --no-seed psql -h localhost -p <port> -U <user> -d <db> -f supabase/seed.sql This bypasses the CLI’s limitation and uses the native psql command which fully supports COPY ... FROM STDIN;

Keep an eye on Supabase CLI updates for future fixes to this issue.

[od-vennre]

Is this intentional, @Ivan-developer0, and is there a place in the documentation or in the source code where this is acknowledged?

I find it intriguing that a seeding mechanism built around PostgreSQL does not support its highly evolved COPY syntax. After all, this is exactly why this syntax is needed, to seed databases with data efficiently.

May I ask why is it currently unsupported? Is it failing SQL syntax checks? Does other forms of COPY work, for example, from a CSV file?

I look forward to your reply and explanation.

[Ivan-developer0]

⚠️ Supabase CLI Limitation Notice

Yes, this behavior is intentional. The Supabase CLI currently does not support the COPY ... FROM STDIN; syntax due to how it handles SQL file execution. The CLI does not emulate psql’s streaming input, which STDIN relies on.

---

❓ Why Doesn’t It Work?

The COPY ... FROM STDIN; command expects a live input stream, which tools like psql handle natively. Supabase CLI, however, reads SQL files as text and executes them in a way that cannot simulate interactive STDIN behavior.

---

✅ Alternatives You Can Use

• Use the full COPY ... FROM '/path/file.csv' WITH (FORMAT csv) syntax (may require container-accessible path).
• Convert to standard INSERT statements for small datasets.
• Best workaround:

supabase db reset --no-seed
psql -h localhost -p <port> -U postgres -d postgres -f supabase/seed.sql

This lets you seed the DB using psql, which supports STDIN.

---

📌 Is It Documented?

This limitation is not yet clearly documented but is a known constraint. The CLI’s current parser simply does not handle STDIN-based copy.

---

📢 Feature Request Suggestion

Supporting COPY FROM STDIN in the CLI would greatly benefit developers seeding large datasets. You may want to submit or upvote a feature request for future CLI versions.

---

✅ Summary:

• This is not a bug in your SQL — it’s a CLI limitation.
• Use psql for seed files using COPY FROM STDIN.
• Watch for future CLI improvements or contribute to a feature request.

[Hallidayo]

Hi, I've moved this issue over from the supabase repo.

[tamaro-skaljic]

Stumbled upon this too. 👍