Skip to content

Introduce explicit database migration workflow #178

Description

@maldwg

The backend currently relies on vulnerability_scanner.sql for fresh database initialization. For now, application startup assumes the database schema is already correct and no longer performs schema creation or repair. We need an explicit migration workflow before supporting upgrades of existing database volumes.

Scope:

  • Add a migration tool, preferably Alembic, for backend schema changes.
  • Create a baseline migration matching the current vulnerability_scanner.sql schema.
  • Define how fresh installs and existing installs are handled.
  • Move future table/column/index changes out of FastAPI startup and into ordered migrations.
  • Add deployment documentation for running migrations before starting the backend.

Acceptance Criteria:

  • Backend startup never creates tables or mutates schema.
  • Fresh installs still work from the current SQL bootstrap or an agreed migration bootstrap path.
  • Existing databases can be stamped at the baseline revision.
  • Future schema changes are represented as migrations.
  • Deployment docs explain: DB starts, migrations run, backend starts.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions