awesome-db-audit
Database Audit
Audit a database layer — schema, queries, migrations, and the operational habits around them — for the design defects that surface as slow queries, silent data corruption, and unrunnable migrations in production. Read-only: it reports findings and a verdict; it never edits schema, data, or code. Works from the repo's schema files, migrations, and query sites; a live connection is optional and read-only when present.
Evidence, not taste. Every finding cites its artifact — a file:line in a migration or model, a query site, a schema definition, an EXPLAIN output if a connection exists. A "smelly" table name is a lead; confirm the defect (the missing constraint, the unindexable predicate) before flagging.
Four audit tracks — run the ones in scope:
- A. Schema design — types, keys, and the anti-pattern catalog.
- B. Query patterns and indexes — what the code asks, and whether an index can answer it.
- C. Integrity and concurrency — constraints, transactions, locking strategy.
- D. Migrations and operations — evolution, restore path, seeds, pooling.
Scope and method
- Establish scope — the whole schema, one domain's tables, or the migration history. Name it; findings without a boundary don't prioritize.
- Locate the source of truth — schema files, ORM models, migration directory; note the engine and version (Postgres/MySQL/SQLite behave differently and some findings are engine-specific — say which).
- Read schema before queries — a table designed wrong makes every query against it a finding; start where the defects multiply.
- Grep the query sites — ORM calls and raw SQL both; an anti-pattern that never runs on a hot path is a note, not a FIX. Zero hits is not proof of absence — ripgrep honors
.gitignore; re-scan with ignores off before concluding. - Score, gate, report — see Output.