Observability Stack
pgwatch does not include a dashboarding or alerting engine of its own. The metrics it stores are accessible through whatever sink you chose — Postgres, TimescaleDB, Prometheus, JSON file, or gRPC — and you are free to point any tool that speaks the corresponding protocol at that data. In practice, almost every pgwatch deployment uses Grafana on top, because the project ships a curated set of dashboards specifically designed for PostgreSQL.
Why Grafana
- First-class support for PostgreSQL, TimescaleDB, and Prometheus as data sources — the three sinks pgwatch most commonly targets.
- The shipped dashboards (see the Gallery → Dashboards) expect the standard Postgres function syntax (window functions for counter resets, percentile aggregates for latency panels, etc.).
- Built-in alerting with a graphical rule editor covers most common operational use cases.
Grafana's alerting is convenient for lighter deployments but has limits at scale: alert rules can only attach to Graph panels, and queries with template variables do not work. For enterprise-scale setups, many teams graduate to a dedicated alerting system that consumes Prometheus metrics directly.
Storage recommendations
Pick a sink based on what already exists in your environment.
| Sink | When to use it |
|---|---|
| Postgres (with or without TimescaleDB) | Default. The shipped dashboards and SQL metric queries target this substrate. TimescaleDB adds native compression and chunk-based storage; pgwatch's own admin.drop_old_time_partitions() handles retention either way. Continuous aggregates are out of scope for pgwatch — if you want them, configure TimescaleDB yourself and adapt the Grafana panels. |
| Prometheus | When an external Prometheus server is already the system of record for monitoring data. pgwatch can expose metrics in the Prometheus text exposition format instead of writing to a database. |
| gRPC | When you want to stream metrics into a system pgwatch does not natively support — an external time-series store, alerting system, or analytics pipeline. You implement the receiving server using the protobuf contract under api/pb/. |
| JSON file | Testing, CI, and local development. Writes one file per measurement batch; not intended for production retention. |
Multiple sinks can run side-by-side (see Reference: Sinks options for the MultiWriter mechanism), so the choice is not exclusive — Postgres for dashboards, Prometheus for an existing alerting stack, gRPC for a custom data lake, etc.
Alerting
pgwatch does not have strong opinions about where alerts should fire. What the project provides:
- The same Grafana alerting workflow that works with any other PostgreSQL data source. The shipped dashboards already include the panels most teams start alerting on (high connection count, replication lag, long-running transactions, disk-space growth) — pick one and turn it into a rule.
For the concrete recipe to add alert rules in Grafana, see How-to: Set up alerting. For larger setups, point the gRPC or Prometheus sink at a dedicated alerting system (Alertmanager, Grafana Mimir + Grafana, SaaS, etc.) instead of running Grafana alert rules.