Skip to main content

Elevarq Signals

Open-source PostgreSQL telemetry collector. Safe, lightweight, and designed to run inside your infrastructure.

Open source

Elevarq Signals collects performance telemetry from PostgreSQL instances using read-only access. It gathers execution statistics, wait events, connection metrics, and configuration state — then packages that data for analysis by Elevarq Analyzer or for your own tooling.

Signals is free, open source, and designed to be safe. It connects with the pg_monitor role, reads only from system catalog views, and never modifies your database.

What it collects

  • pg_stat_statements — query execution statistics
  • pg_stat_user_tables / pg_stat_user_indexes — table and index usage
  • pg_stat_activity — active sessions and wait events
  • pg_stat_bgwriter / pg_stat_database — background and database-level metrics
  • pg_settings — current configuration state

Design principles

Read-only access

Signals connects with pg_monitor role privileges. It does not create tables, modify schemas, or write data to your databases.

No data exfiltration

Data stays in your network. Signals packages telemetry into local snapshots. No data is transmitted to external services unless you explicitly configure it.

Air-gap compatible

Signals works in fully offline environments. Schedule it via cron or systemd, collect ZIP snapshots, and analyze them whenever and wherever you choose.

Coming from Oracle AWR?

Familiar historical evidence for your PostgreSQL databases, the PostgreSQL-native way.

If you have run Oracle databases, you have probably leaned on AWR to see what the database was doing over time. Elevarq Signals gives PostgreSQL teams the same kind of historical evidence, collected the PostgreSQL-native way: read-only, from the statistics views PostgreSQL already exposes, with no agent inside the database.

  • The workload, captured over time

    Signals records PostgreSQL's own cumulative statistics on a schedule: transactions and commits, cache and disk activity, WAL and checkpoint work, temporary-file usage, and per-table and per-index access. The evidence to reconstruct what the database was doing later is collected, not thrown away.

  • The heaviest SQL, by the database's own numbers

    When pg_stat_statements is enabled, Signals captures per-statement execution counts, total and average time, rows, and block activity, together with the normalized query text. That is the raw material for finding the statements that cost the most.

  • What changed, not only what is slow

    Signals also records configuration and extension state: settings and their restart-pending status, and per-database and per-role overrides. A change in behavior can be lined up against a change in the environment.

  • Read-only and least-privilege

    Signals connects with the pg_monitor role, never a superuser, reads only system views, and changes nothing. It is safe to run against a production database.

  • Yours, and portable

    Snapshots stay in your network and work offline. Collect them on a schedule and analyze them whenever and wherever you choose.

What this is not

  • This is interval evidence from periodic snapshots, not per-second session sampling: very short-lived sessions, locks, and spikes that come and go between snapshots are not individually captured.
  • Signals reports the statistics PostgreSQL exposes. It does not capture SQL execution plans, and it does not read operating-system or host metrics.

Oracle and AWR (Automatic Workload Repository) are trademarks of Oracle Corporation, used here for identification and comparison only. Elevarq is not affiliated with, or endorsed by, Oracle Corporation.