Unused or oversized indexes
Index audit
Postgres write amplification check from evidence-focused evidence
Database Optimization Tool surfaces collector-supported signals that can point to write amplification risk, then leaves diagnosis and production changes to human review.
Write-heavy workloads
Index size context
Team verification
What the collector can support
The check uses evidence the collector can read: relation size, index size, idx_scan, table scan counts, dead-row signals, and available query statistics. It can highlight unused or oversized indexes that may add write cost.
Why write-heavy workloads matter
Every extra index can add work to inserts, updates, deletes, vacuum, and storage churn. The risk is higher when a table has heavy writes and the index has low scan value or unclear query coverage.
Candidate, not conclusion
A large low-scan index is a review candidate, not proof. Statistics can reset, rare batch jobs may depend on the index, and uniqueness or constraint behavior can make an index necessary.
Team verification path
The Team verification path means reviewing recent workload, confirming constraints, checking application release timing, running EXPLAIN for covered queries, testing changes in staging, and keeping a recreate script before any production index removal.
FAQ
Frequently asked questions
These answers describe the product focus: careful database evidence, clear findings, and team-approved next steps.
Does this page diagnose all PostgreSQL write amplification?
No. It follows collector-supported signals. It can show index and workload evidence that deserves review, but it cannot prove every source of write cost.
Are unused indexes always safe to drop?
No. idx_scan can reset, rare reports can need an index, and primary, unique, or constraint-backed indexes need special handling. Treat the finding as a manual review queue.
What makes an oversized index important?
Size matters when it is paired with low observed use, write-heavy table behavior, vacuum pressure, or storage churn. Size alone is not enough for a production change.
What should happen before a write amplification fix?
Confirm the workload, validate query plans, check dependency and constraint role, stage the change, and prepare rollback SQL. Database Optimization Tool does not change indexes.