awesome-database-auditlisted

# 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 1. Establish scope — the whole schema, one domain's tables, or the migration history. Name it; findings without a boundary don't prioritize. 2. 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). 3. Read the project's own words — its glossary (`CON