cloudparts

PoWA

PostgreSQL Workload Analyzer: snapshots pg_stat_statements and related extensions into a PostgreSQL repository, and shows per-query history, wait events and index suggestions in a web UI.

What it is
Metrics
Used for
Observability
Type
Open source
Made by
The PoWA team (started at DALIBO)
License
PostgreSQL License
Facts checked
23 October 2026
Website Source code

What it is

PoWA is built from PostgreSQL extensions and two small programs. pg_stat_statements is the one required data source: it keeps cumulative counters per normalized query. Optional extensions add more: pg_qualstats samples the predicates in WHERE and JOIN clauses, pg_stat_kcache adds the real reads and writes the filesystem did for each query, pg_wait_sampling samples wait events and pg_track_settings records configuration changes and restarts. The powa extension, powa-archivist, takes snapshots of these counters on a schedule (every 5 minutes by default), stores them compactly and purges old data (after 1 day by default). powa-web, a Python and Tornado application, turns the deltas between snapshots into graphs per server, database and query.

There are two ways to run it. In local mode a background worker inside each server takes the snapshots, which needs a restart, adds overhead, and can’t work on read-only standbys. The recommended remote mode, added in PoWA 4 (2020), stores everything on a separate repository database: the powa-collector daemon connects to each registered server, including standbys, and copies the snapshots there. With pg_qualstats installed, PoWA suggests missing indexes for one query or the whole workload of a database, and with HypoPG on the target database it creates each suggested index hypothetically and checks with EXPLAIN whether the planner would use it. PoWA is free under the PostgreSQL License. Version 5.0 (November 2024) was a rework with no upgrade path; 5.3, in August 2026, followed changes in the PostgreSQL 19 betas.

Why teams pick it

  • History per normalized query: calls, time, rows, block I/O and, with pg_stat_kcache, real filesystem reads and writes, for every snapshot
  • Index suggestions for a whole database’s workload, checked with hypothetical indexes before you build anything
  • Remote mode keeps the stored data and the UI’s queries off production servers and covers standbys
  • Its extensions also cover pg_stat_activity, pg_stat_io, replication, WAL, archiver and wait events, so one UI shows server-wide activity too

Watch out for

  • Each monitored server still needs pg_stat_statements and any other stats extensions in shared_preload_libraries, which means a restart and, on managed services, only the extensions the provider offers
  • Several parts to install and keep in step: extensions on every server, a repository database, powa-collector and powa-web; 5.0 had no upgrade path from 4.x
  • Reports rely on counters only ever growing; calling pg_stat_statements_reset() makes them meaningless for that period
  • pg_qualstats samples 1% of queries by default, so index suggestions need time or a higher sample rate, which costs performance on busy servers

Alternatives

What all metrics have in common →Compare side by side →
pgwatchOpen sourceA PostgreSQL-only monitoring collector from CYBERTEC: metrics are plain SQL queries run on a schedule, stored in Postgres, TimescaleDB or Prometheus, and shown in ready-made Grafana dashboards.

How it fits with other technologies

Remote mode: register a monitored server on the repository database · sql

-- On the repository server, in a dedicated database
CREATE DATABASE powa;
\c powa
CREATE EXTENSION pg_stat_statements;
CREATE EXTENSION btree_gist;
CREATE EXTENSION powa;

-- Declare a remote server and the stats extensions it has;
-- powa-collector then snapshots it and stores the data here
SELECT powa_register_server(hostname => 'myserver.domain.com',
    alias => 'myserver',
    password => 'mypassword',
    extensions => '{pg_stat_kcache,pg_qualstats,pg_wait_sampling}');

See it in a real stack

No architecture uses PoWA yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2014–2026

PostgreSQL’s pg_stat_statements shows totals since the last reset, not how a query behaved yesterday at 3 p.m. PoWA began at the PostgreSQL company DALIBO in 2014 to keep snapshots of those counters and chart them; its first releases had a Perl web interface built on Mojolicious.

PoWA 2.0, in March 2015, split the project into powa-archivist, the extension that stores snapshots, and powa-web, a rewritten interface in Python on Tornado, and added pg_qualstats and pg_stat_kcache. PoWA 3.0, in December 2015, used predicate statistics to propose the smallest set of indexes for a whole database, checked with HypoPG’s hypothetical indexes. PoWA 4.0, in April 2020, added remote mode and powa-collector, so data could live on a separate server and standbys could be monitored.

Since 2018 the copyright has been held by the PoWA team rather than DALIBO. PoWA 5.0 followed in November 2024 as a rework that adds server-wide statistics views; releases in 2026 have kept pace with PostgreSQL 19.

Why it’s built this way

Build on PostgreSQL extensions rather than an external agent
The statistics already live inside the server, in pg_stat_statements and friends, so an extension can read them and keep a consistent view across PostgreSQL versions.
Store snapshots in PostgreSQL itself
No extra database to run: the history is ordinary tables that PoWA aggregates and purges, and powa-web reads them with SQL.
Add a remote mode in version 4
A background worker on each server cost performance, needed restarts and couldn’t write on read-only standbys; a collector writing to a separate repository fixed all three.

Timeline

  1. 2014

    PoWA 1.0 at DALIBO

  2. 2015

    PoWA 2.0 splits archivist and web UI; 3.0 adds whole-database index suggestions

  3. 2020

    PoWA 4.0 adds remote mode and powa-collector

  4. 2024

    PoWA 5.0, a rework with no upgrade path

  5. 2026

    PoWA 5.3 follows PostgreSQL 19 beta changes

Sources13 · facts checked 23 October 2026

Improve this page on GitHub