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.
The backend currently relies on
vulnerability_scanner.sqlfor 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:
vulnerability_scanner.sqlschema.Acceptance Criteria: