A pure SQL Active Session History extension for PostgreSQL that samples wait events every second with zero storage bloat.
pg_ash is a pure SQL Active Session History implementation for PostgreSQL that samples database wait events and query activity at regular intervals. It solves the problem of historical performance visibility in PostgreSQL by capturing snapshots of `pg_stat_activity` and storing them in an efficient, queryable format. This allows database administrators to investigate past performance issues and analyze wait event patterns long after they occurred.
PostgreSQL database administrators, DevOps engineers, and SREs who need historical performance monitoring on managed PostgreSQL services or any PostgreSQL 14+ instance. It's particularly valuable for teams using RDS, Cloud SQL, Supabase, or other managed providers where traditional monitoring extensions aren't supported.
Developers choose pg_ash because it provides enterprise-grade session history functionality without the complexity of C extensions or external monitoring systems. Its pure SQL implementation means it works everywhere PostgreSQL runs, its zero-bloat storage design ensures predictable performance, and its rich analytical functions enable deep performance investigation with simple SQL queries.
Active Session History for PostgreSQL — wait event sampling with zero bloat (pg_cron + PGQ-style partition rotation)
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Implemented entirely in SQL and PL/pgSQL, pg_ash requires no C extensions or shared_preload_libraries, making it instantly deployable on any PostgreSQL 14+ instance, including managed services like RDS and Supabase.
Uses a three-partition ring buffer that rotates daily via TRUNCATE, eliminating dead tuples and vacuum overhead, ensuring predictable storage usage of about 30 MiB per day for 50 active backends.
Provides numerous built-in functions like top_waits(), timeline_chart(), and activity_summary() that enable detailed performance investigation with simple SQL queries, complete with visual bar charts and ANSI color output.
Functions chain naturally for step-by-step analysis, making it ideal for AI-assisted troubleshooting, as demonstrated in the README's example of an LLM investigating a lock contention issue.
Relies on pg_cron for scheduling, which can fail to keep up with 1-second intervals during heavy database load, leading to missing samples precisely when monitoring is most critical.
Cannot be installed on physical standbys or read replicas because it requires write access for inserting samples and rotating partitions, restricting deployment to primary databases.
Generates approximately 2.4 GiB of WAL per day at 1-second sampling, which can strain replication setups or backups, necessitating interval adjustments in WAL-sensitive environments.