feat(seed): Add new flag option for setting custom seed file path

[coolusaHD]

What kind of change does this PR introduce?

Feature

What is the current behavior?

Currently, supabase db reset only supports two seed behaviors:

Run the default seed file(s) defined in config (e.g. supabase/seed.sql)
Skip seeding entirely with --no-seed
There is no way to specify an alternative seed file at runtime. Users who want to reset their database with different initial data (e.g., an empty state with minimal setup vs. a full product example) must either:

Manually swap seed files before running reset
Skip seeding and manually run the desired seed file afterward

What is the new behavior?

Added a new --override-seed-file flag to supabase db reset that allows specifying a custom seed SQL file path:

The --override-seed-file and --no-seed flags are mutually exclusive since using both doesn't make sense.

Additional context

Add any other context or screenshots.

[Copilot]

Pull request overview

This PR adds a new --override-seed-file flag to the supabase db reset command, allowing users to specify a custom seed SQL file at runtime instead of using the default supabase/seed.sql. The flag is mutually exclusive with --no-seed.

Key Changes:

• New --override-seed-file flag added to override the default seed file path
• Mutual exclusivity enforcement between --no-seed and --override-seed-file flags
• Documentation updated to describe the new flag and its use case

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
docs/supabase/db/reset.md	Added documentation explaining the new --override-seed-file flag and its use case for specifying custom seed files
cmd/db.go	Introduced overrideSeedFile variable, flag registration, mutual exclusivity setup, and logic to update SqlPaths when the flag is provided

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sweatybridge]

You can specify custom seed paths via config.toml

[db.seed]
# If enabled, seeds the database after migrations during a db reset.
enabled = true
# Specifies an ordered list of seed files to load during db reset.
# Supports glob patterns relative to supabase directory: "./seeds/*.sql"
sql_paths = ["./seed.sql"]

[coolusaHD]

You can specify custom seed paths via config.toml

@sweatybridge Thanks for having a look at my PR. The reason why I want to add an seed file flag is that the config.toml support only one state of seed files. I also currently use a project with musltiple seed files but they dont cancel each other out.

What I need for my project is that I have a seed file which contains a complete filled databse with test data for everthing. But I want to have a second seed state where just the basic outline data is filled into the database to like simulate the beginning of a new client, etc.

Let me know what you think about that 🙌

[coolusaHD]

@sweatybridge Any update on this ?

[kevin-brotcke]

We need this feature too. I'm not really seeing a good alternative if you run a lot of tests with specific seed data. The workarounds I can think of all seem kind of hacky:

1. Run a sed command to update the config.toml file
2. Move/copy seed files via shell commands
3. Use the --workdir param to point to another supabase directory with different config.toml and seed data. I like this but now you have dups of the entire supabase infra folder that's bound to get out of sync.

I actually think a more reusable solution would be to set a config.toml path via runtime. Or a config override path that will merge with base config. The logic looks like it's already there for branch specific config values.

[coolusaHD]

@kevin-brotcke I invited you to my fork
Feel free to add your suggestions
I'm more than happy to see others are also struggel with that

[jgoux]

Hey, thanks for your contribution! 🙏

I opened #5691 to address the issue with a new repeatable --sql-path flag which overrides the value in config.toml.

In the future we will maybe look into having seeds profiles.

Thanks again for addressing the issue!