PoWA gathers PostgreSQL statistics and charts them across your servers

A monitor for PostgreSQL, not a query tool

PoWA is a PostgreSQL Workload Analyzer. It gathers performance stats and provides real-time charts and graphs to help monitor and tune your PostgreSQL servers.

That definition places it in a specific niche. It is not a query console, and it is not a log aggregator. Its subject is the behaviour of the server itself, and its output is a set of charts that show how that behaviour moves over time.

The reason to want that is continuity. A single snapshot of PostgreSQL's statistics tells you what is happening now. The problem is that the interesting failures are rarely happening now. A query that took 40 milliseconds yesterday and takes four seconds today is only visible if somebody kept the history, and a monitor that keeps history across a fleet of instances is the thing that makes the comparison possible.

The documentation is the authoritative source and it lives at powa.readthedocs.io. The README is deliberately short, and for a project whose main repository is the documentation, that is worth understanding before you start: what you are looking at here is the manual, and the code lives next door in four other repositories.

The project is under the PostgreSQL licence, the last push to the default branch was on 2026-09-03, and the repository has no GitHub releases, so the deployment story lives entirely in the documentation.

Four repositories: collector, interface and two extensions

The README's section on where the code is is the most useful thing in it, because it explains the architecture without a diagram.

This repository contains the PoWA documentation. The source code is split across multiple separate projects, and the README names them with one line each.

PoWA-archivist is the statistic collector. It is the component that talks to your PostgreSQL instances and gathers the numbers.

PoWA-web is the graphic user interface, the part where the charts appear.

pg_qualstats is an extension to sample predicate statistics, which is the detail that lets a monitor show which query predicates are selective, rather than only which queries are slow.

pg_stat_kcache is an extension to sample operating system metrics, which is how a database monitor can show what the server was doing at the operating system level, cache behaviour included, rather than only what PostgreSQL thinks happened.

Other extensions are supported as well, and the README refers to the documentation for a complete list, with a link to the stats extensions page in the components section. That list is the real integration surface of the project, because the archivist can only chart what an extension can collect.

So the mental model is a collector that polls, a set of extensions that expose the raw data, and a web interface that stores and draws the history. Which extensions you enable decides what you can see.

Version support is stated bluntly, including the old branch

The README carries a warning block, and it is the most operationally useful paragraph in the file.

The current version of PoWA is designed for all PostgreSQL versions supported by the community, and for EOL versions down to 9.4. If you are using PostgreSQL 9.3, the README says you should use PoWA version 1.x, and it gives both places to go: the code on the REL_1_STABLE branch of this repository, and the documentation under the rel_1_stable version of the site.

The interesting part is that the old branch lives in the same repository as the current documentation. A project that has been running long enough to still support 9.4 has to keep two lines alive, and the way this one does it is by branching rather than by maintaining separate tags.

For an adopter this translates into a concrete question at install time: which PostgreSQL version is on the server, and which PoWA line matches it. The current line covers a lot of ground, including versions the community no longer supports, which is a statement about how many production databases in the world are still on old releases.

The documentation site carries both versions, so the same readthedocs URL structure serves the current manual and the 1.x manual, and the versions are selected by the path.

What the demo instance reveals about the resource cost

The README offers a live demo at demo-powa.anayrat.info, and the invitation comes with a warning about what you are about to see.

The note explains that resources have been limited on that server, specifically 2 vCPU, 384MB of RAM and 150iops for the disks, and that you should be patient when using it. The point being made is not an apology but an instruction: the metrics you get are limited by the machine producing them.

That is a useful piece of engineering honesty, and it carries a lesson for anyone planning a deployment. A workload analyzer is an observer, and an observer that samples heavily costs something on the server it observes. The 150iops figure in particular is a reminder that disk operations, not CPU, are often what a monitoring stack taxes.

It also tells you what the tool does not do. The demo exists so you can click Login and try the features, and the README credits the person who provided it. It is a demonstration of the interface, and the constrained hardware means the graphs on it are not a picture of a well provisioned deployment.

The documentation is where the real deployment guidance lives, and it is at powa.readthedocs.io.

The alternative is reading PostgreSQL's own statistics yourself

There is a perfectly good alternative to PoWA, and it is the thing PostgreSQL already gives you.

PostgreSQL exposes its own statistics through system views, and a monitoring tool can read those views directly. The difference in approach is where the data goes and who keeps it.

Reading the views directly means no collector to install, no extensions to enable beyond what you choose, and no extra service to operate. What you do not get is history. The views describe the current state, and a query against them tells you what is happening now rather than what was happening an hour ago, unless you have already built the storage to keep it.

PoWA's approach is the opposite. It installs an archivist that talks to each server, and it stores what it collects, so the charts have a time series behind them and you can compare instances with each other. The cost is the collector, the extensions, and the storage the archivist keeps.

There is also a middle path that PoWA is explicit about: the sampling extensions. pg_qualstats and pg_stat_kcache exist because the built-in views do not expose everything a workload analyst wants, and each one you enable widens the picture at the cost of more work on the server.

For a single database that someone queries occasionally, reading the views is enough. For a fleet, or for a server where you need to answer what happened last Tuesday, the collector and its history are the reason PoWA exists.

Licence, contribution and the shape of the project

The licence is the PostgreSQL licence, recorded in the repository as LICENSE.md, which is the permissive open source licence PostgreSQL itself uses.

The repository itself is a documentation project. Besides the README it holds a docs directory, the images used by the manual, a .readthedocs.yaml file that drives the Read the Docs build, and a CONTRIBUTING.md. There is no source tree to speak of, no build to run locally for the application, and no release artefacts.

That shape has a practical consequence for anyone evaluating the project. You cannot judge PoWA by reading this repository, and there is no single command that installs it. The evaluation happens in the documentation and in the four code repositories, and the decision you are really making is which components to deploy and which extensions to enable on your servers.

The extension list is where the real configuration lives. The README refers to the documentation for the complete list of supported statistics extensions, and each extension adds a specific kind of observation: predicate statistics from pg_qualstats, operating system metrics from pg_stat_kcache, and whatever else the project supports. Each one is a separate installation on each monitored server, and each one is a separate thing to trust and to keep compatible with your PostgreSQL version.

The contributions are spread across those repositories too, which is normal for a project of this shape and worth knowing before you open an issue about something that looks like it belongs here.

Editorial conclusion

Adopt PoWA when you run more than one PostgreSQL instance and want a single place to watch their performance over time, and when you can install the collector and the sampling extensions on the servers themselves. Do not adopt it for a single small database, where the built-in statistics views answer the same questions with no extra footprint, and check the version policy first, because the current line covers community supported versions and EOL versions down to 9.4 while PostgreSQL 9.3 needs the separate 1.x branch. Before you deploy, read the components documentation at powa.readthedocs.io, decide which sampling extensions you need, and plan for the fact that the archivist keeps its own storage for the history it charts.

Frequently asked questions

Official sources

1. Issues
2. License: PostgreSQL
3. powa-team/powa on GitHub
4. Project website
5. README