Skip to Content

gofasta db

Grouping for operations that wipe or recreate schema. These live under their own command rather than beside gofasta migrate precisely because they are destructive — the separation exists so nobody reaches for one by muscle memory while meaning to run a migration.

gofasta db [command]

Currently one subcommand: reset.

gofasta db reset

Rebuilds the database from nothing.

gofasta db reset

Flags

FlagTypeDefaultDescription
--skip-seedboolfalseStop after migrations — reset the schema without loading fixtures.

The global --json flag applies as well.

What it does

Three steps, in order, each timed:

  1. migrate drop -f — drops every table, including schema_migrations.
  2. migrate up — re-applies every migration from version 1.
  3. go run ./app/main seed — runs the project’s registered seed functions. Skipped with --skip-seed.

A failing step stops the run; the steps that already completed are reported with their status so you can see how far it got.

Before any of that, .env is loaded into the environment. Scaffolded projects keep their credentials there, and Docker Compose maps the database to a host port that differs from the in-container port — loading .env first is what lets both the migrate shell-out and the spawned seed process reach the same database.

Examples

# Full rebuild: drop, migrate, seed gofasta db reset # Schema only — no fixtures gofasta db reset --skip-seed

JSON output

$ gofasta db reset --json { "steps": [ { "name": "drop", "status": "ok", "duration_ms": 118 }, { "name": "migrate up", "status": "ok", "duration_ms": 342 }, { "name": "seed", "status": "ok", "duration_ms": 205 } ], "duration_ms": 665 }

Each step’s status is ok, fail, or skip, with message carrying the failure reason when one applies. Per-step timings make it obvious which phase is slow when a reset starts dragging in CI.

This is irreversible

db reset destroys all data in the configured database. There is no confirmation prompt and no undo. Never point it at a shared staging database or anything resembling production. If you are unsure which database your config.yaml and .env currently resolve to, run gofasta doctor first — it reports the resolved connection and whether the database is reachable.

Requirements and configuration

Connection details are read from config.yaml, overridable with GOFASTA_-prefixed environment variables, using the same driver resolution as gofasta migrate. Schema work is delegated to golang-migrate , which must be installed and on your PATH — gofasta doctor checks for it.

Failures surface as DATABASE_RESET_FAILED; see Error codes.

Last updated on