4.1k stars · PostgreSQL License | [pgbadger.darold.net](http://pgbadger.darold.net/) · v13.2 (2025-12-29) · Track this in Rising ↗
It reads PostgreSQL's own log file and writes one page naming the slowest queries.
Radar check
What we found when we opened it. Every bar is one fact, with its date.
Last code pushed 21 Oct 2026, 6 days before this check.
Latest release v13.2 on 29 Dec 2025.
Public since April 2012, a little over 14 years.
4,072 stars and 379 forks.
23 commits and 2 new issues in the last 90 days.
97 contributors. 5 pull requests merged in 90 days.
No security policy file says how to report a problem. No published security advisories.
How the bars are scored
- Alive. Days since the last code push: a week or less 100, a month 90, three months 70, six months 50, a year 30, eighteen months 15, older 0.
- Releases. Age of the latest GitHub release, on a similar scale; no bar when the project publishes no releases.
- Maturity. Age of the project: eight years 100, five 90, three 70, two 55, one 40, six months 25, younger 10.
- Adoption. Stars on a log scale: 100,000 stars is 100, 10,000 is 80, 1,000 is 60, 100 is 40.
- Activity. Commits in the last 90 days: 300 or more 100, 100 85, 30 65, 10 45, any 25.
- Community. People who have contributed: 100 or more 100, 30 80, 10 60, 5 40, 2 25, one 10.
- Security. A published security policy 80, none 40; published advisories are listed, not scored.
Checked by Repo Radar on 25 Oct 2026 from the repository on GitHub. Covered in Edition 18.
▶Repo detailsthe review · specs · pros & cons · install
What it does
pgBadger is a single program that reads PostgreSQL log files and produces one self-contained HTML report. The report names the slowest queries, the most frequent ones, and the ones that cost the most time in total, with charts over the day. It also reports connections, locks, temporary files, checkpoints and errors. It can read compressed logs, several files at once, and logs from a remote machine. It can run over a long period in pieces and combine the results. Version 13.2 arrived on 29 December 2025, and the newest code change landed on 15 September 2026. It does not watch a database continuously, and it offers no alerts and no live dashboard.
Why it matters
Who it suits. It suits anyone whose own application is getting slower with no obvious cause, because it answers the question directly instead of asking for monitoring to be installed and a week to pass. It suits a one-off investigation, since nothing is left running afterwards. It is also the quickest way to find work that walks through a long list of records and quietly runs one small query per record. Skip it if what is wanted is a live dashboard and alerts, and skip it if query logging cannot be switched on even for a day.
Verdict. Worth half an hour, and the report usually pays for itself the first time. Two cautions. A useful report needs query logging switched on in PostgreSQL first, which writes more to disk, so free space is worth watching for that day. And it is written in Perl, an older programming language, so installing it is a package rather than a one-line Python install. dalibo/pev2 is the natural next step once the slow query is known, and cybertec-postgresql/pgwatch is the choice if continuous monitoring is what is actually wanted.
Summary (Key Points)from the README
Key features
- Parallel parsing: The `-j N` option parses one file across N cores, and `-J N` assigns one core per log file. The README's benchmark used a single 9.5GB file on 8 CPUs.
- Hourly detail: Some reports come with hourly charts divided into five-minute periods.
- Histogram granularity: The `-A` option sets histogram granularity, down to the minute.
- Interactive charts: Charts are zoomable and can be saved as PNG images, and SQL queries are highlighted and beautified automatically.
- Format autodetection: pgBadger detects syslog, stderr, csvlog or jsonlog formats when the file is long enough.
- Compressed input: It reads gzip, bzip2, lz4, xz, zip and zstd files directly, and you can mix formats when autodetection is used.
- Remote and URI sources: It reads remote logs over passwordless SSH, or from http(s), (s)ftp and ssh URIs. In watch mode, SSH logs are filtered on the remote host before transfer.
- Incremental reports: Incremental mode creates one report per day and a cumulative report per week, with optional per-database subdirectories.
- PgBouncer and other formats: It parses PgBouncer logs, Heroku logplex, RDS/CloudWatch, CloudSQL JSON and CloudNativePG logs.
- Self-contained output: It is a single Perl script with embedded JavaScript and CSS, so reports need only a web browser.
Important
- Locale: The parser only handles PostgreSQL messages in English. Other locales such as fr_FR.UTF-8 are not supported.
- Logging settings: Do not enable log_statement, because pgBadger cannot parse its format. Enabling log_min_duration_statement, log_duration and log_statement together produces wrong counters and a much larger log.
- Parallel limits: Multiprocessing cannot be used with compressed files, CSV files or Windows. With -j, pgBadger may truncate or omit up to N queries per log file.
- Temporary files: Parallel parsing writes files named tmp_pgbadgerXXXX.bin to /tmp. Do not delete them while pgBadger is running.
- Remote mode: Remote SSH parsing cannot be used with the CSV log format.
- Compression requirements: xz support requires xz above 5.05 with the --robot option. lz4 files must be compressed with --content-size so pgBadger can determine the uncompressed size.
- Optional Perl modules: CSV parsing and JSON export each need an extra Perl module. Neither is needed otherwise.
- Monthly reports: These are not built by default and must be requested separately. The README warns they can take a long time on large data sets.
Written by an AI model from the project’s README; not part of the review, and it can be wrong.
- It works on log files that already exist, so it can explain last week.
- Nothing is left running on the machine. Run it, read the page, done.
- The report is one HTML file, with no database and no dashboard to maintain.
- Query logging has to be switched on first, which writes more to disk.
- It is written in Perl, so it is a system package rather than a quick language-specific install.
- It explains the past. It raises no alarm while something is going wrong.
# Debian and Ubuntu package it directly: sudo apt update sudo apt install pgbadger # Switch on query logging in postgresql.conf: # log_min_duration_statement = 0 # log_line_prefix = '%t [%p]: user=%u,db=%d,app=%a,client=%h ' # log_checkpoints = on # log_lock_waits = on # log_temp_files = 0 # Reload PostgreSQL, let it run for a day, then: pgbadger /var/log/postgresql/postgresql-16-main.log -o ~/report.html
