---
checkId: check.db.migrations.pending
plugin: stellaops.doctor.database
severity: warn
tags: [database, migrations, postgres, schema]
---
# Pending Migrations

## What It Checks
Looks for the `__EFMigrationsHistory` table and reports the latest applied migration recorded there.

This runtime check does not diff the database against the assembly directly; it tells you whether migration history exists and what the latest applied migration is.

## Why It Matters
Missing or stale migration history usually means a fresh environment was bootstrapped incorrectly or schema changes were never applied on startup.

## Common Causes
- Startup migrations are not wired for the owning service
- The database was reset and the service never converged the schema
- The service is using a different schema owner than operators expect

## How to Fix

### Docker Compose
```bash
docker compose -f devops/compose/docker-compose.stella-ops.yml logs --tail 200 doctor-web
docker compose -f devops/compose/docker-compose.stella-ops.yml exec postgres psql -U stellaops -d stellaops -c "SELECT \"MigrationId\" FROM \"__EFMigrationsHistory\" ORDER BY \"MigrationId\" DESC;"
```

Confirm the owning service calls startup migrations on boot instead of relying on one-off SQL initialization scripts.

### Bare Metal / systemd
```bash
journalctl -u <service-name> -n 200
dotnet ef migrations list
dotnet ef database update
```

### Kubernetes / Helm
```bash
kubectl logs deploy/<service-name> -n <namespace> --tail=200
kubectl exec -n <namespace> <postgres-pod> -- psql -U <db-user> -d <db-name> -c "SELECT COUNT(*) FROM \"__EFMigrationsHistory\";"
```

## Verification
```bash
stella doctor --check check.db.migrations.pending
```

## Related Checks
- `check.db.migrations.failed` - diagnose broken runs before retrying
- `check.db.schema.version` - validates the resulting schema shape