PWR (PostgreSQL Workload Repository) is a PostgreSQL monitoring tool built for DBA, DevOps, SRE and operations teams. It captures lightweight snapshots and helps you find the root cause of slow queries, locks and other PostgreSQL incidents in minutes.

Pick any before/after pair - a deployment, an incident, or a slow period - and PWR instantly computes the delta across slow queries, lock waits, wait events and key metrics.

Yes. PWR is designed for safe use in production. It relies on a dedicated schema for its own technical writes (metadata, snapshots), while the application user used for collection only has read access to the PostgreSQL catalogs required for observability. The product also includes purge mechanisms to control disk usage, with a configurable capture frequency and retention period so you can limit load and data volume on your database.

Yes. PWR is built for PostgreSQL incident analysis and release-regression detection - replay what happened during an incident and pinpoint the root cause without digging through raw logs.

PWR complements your existing PostgreSQL monitoring stack by focusing on root cause analysis: before/after comparison, weighted health scoring, and plain-language reports your whole team can read.

Yes. PWR uses customer-controlled, read-only access to a dedicated schema created just for its own objects - it never writes to your application tables. You can revoke access or purge/drop everything at any time.

Yes, the trial is free for 15 days. A credit card is required at signup.

Yes, you can cancel anytime from your account, before the end of the 15 days.

Your data stays hosted on your own infrastructure. PWR runs against your PostgreSQL environment, and depending on your security requirements, you can choose either deployment mode. You keep control over access and data retention.

The demo lets you discover the product for free. The trial gives you full access for 15 days (credit card required).

Effective PostgreSQL monitoring combines three layers: the instant state (active sessions, connections, cache hit), historical snapshots comparable over time, and a single health score summarizing these metrics. PWR captures all three layers automatically, every minute, with no complex setup.

First identify costly queries with pg_stat_statements (sorted by mean execution time), then confirm the cause with EXPLAIN ANALYZE. PWR automates this ranking and keeps a history per query to pinpoint exactly when a regression appeared, without querying pg_stat_statements by hand.

Sessions blocked by a lock show up in pg_stat_activity with wait_event_type = 'Lock', and wait events (CPU, IO, LWLock...) break down what each active session is really waiting on. PWR surfaces both in real time and keeps a history to spot recurring contention.

Enable the extension via shared_preload_libraries then CREATE EXTENSION pg_stat_statements, then query the view sorted by mean_exec_time, calls, or shared_blks_read depending on what you're after. PWR goes further by capturing its state in persisted snapshots, so you can compare two periods without depending on a reset that would wipe the history.

Pick a snapshot from before and one from after the period you want to analyze (a deployment, an incident, a load spike): PWR automatically computes the delta on queries, locks, and key metrics, and generates a root-cause-oriented report in seconds.

Yes. PWR connects like a standard read-only PostgreSQL client: on-premise, VM, container/Kubernetes, or a managed database (RDS, Cloud SQL, Azure Database) - as long as a normal PostgreSQL network connection is possible, PWR works regardless of your upstream application architecture.

Yes. PWR doesn't drive failover itself, it simply monitors whichever PostgreSQL instance you point it at. On a failover event (Patroni, repmgr, pg_auto_failover...), point PWR at the stable endpoint that always tracks the current primary (VIP, application DNS, or an HAProxy endpoint) rather than a fixed IP, and monitoring continues uninterrupted after the switch.

Yes. PWR relies only on standard, stable PostgreSQL catalogs and views (pg_stat_activity, pg_stat_statements, pg_locks, pg_settings) present across every currently maintained major version - no dependency on version-specific internals.

Yes. PWR works whether or not your application traffic goes through a pooler like PgBouncer or pgpool. We recommend connecting PWR directly to the PostgreSQL instance (bypassing the pooler) so it has full visibility into sessions and doesn't consume pooled connections meant for your application.

No, the impact is designed to be negligible. PWR only runs lightweight read queries against PostgreSQL's statistics views, at a configurable frequency (every minute by default), with purge mechanisms to control data volume - no application query is ever modified or slowed down.

It depends on the replica type. On a logical replica (logical replication): yes, it accepts writes, so PWR's dedicated schema can be installed there normally. On a physical replica (streaming replication): no, it's strictly read-only and PWR needs to write into its dedicated schema to store its snapshots - install PWR against the primary instead in that case, or let's discuss it together on the call to pick the right topology for your needs.

No. PWR never reads your application data or table contents: it only relies on PostgreSQL's own statistics catalogs and views (pg_stat_statements, pg_stat_activity, pg_locks), which hold aggregate metrics (execution times, locks, wait events) - never your actual business data or personally identifiable information (PII).

Yes. PWR's Tuning Advisor analyzes 30 days of your database's real metrics to automatically recommend the 7 most impactful PostgreSQL parameters - shared_buffers, work_mem, effective_cache_size, max_connections, maintenance_work_mem, random_page_cost and wal_buffers - each with its formula, severity level and confidence score.