Skip to main content

What Elevarq detects

Elevarq analyzes every snapshot against a library of deterministic, evidence-grounded rules spanning day-to-day PostgreSQL operations — from vacuum and indexing to configuration, replication, security, and TimescaleDB. Every finding cites the evidence behind it.

The rules below are deterministic — the same evidence always produces the same finding — and each one arrives with the snapshot rows and catalog values it is based on. Some rules compare runs over time to catch trends (a query getting slower, dead tuples accumulating, WAL climbing). This list grows with every release.

Vacuum, bloat & wraparound

The maintenance debt that quietly turns into an incident.

  • Autovacuum falling behind on a table (dead-tuple backlog)
  • Sustained dead-tuple growth across runs
  • Table and index bloat, by size band
  • Transaction-ID / multixact wraparound risk, with the blocking transaction
  • Long-held prepared transactions blocking vacuum

Indexing

Indexes that cost more than they earn — and the ones that are missing.

  • Unused indexes consuming write and storage overhead
  • Duplicate or otherwise unhealthy indexes
  • Index bloat
  • Indexes on high-churn columns (write amplification)
  • Foreign key without a supporting index
  • Index usage that shifted between runs

Query performance

Where time and CPU actually go, and why.

  • A query's execution time regressing between runs
  • Single queries dominating CPU
  • Non-sargable predicates that skip the index
  • Queries spilling to temp files (work_mem sizing)
  • Parallelism available but not being used

Configuration & memory

Settings that stopped matching the workload — sized to your host.

  • shared_buffers, effective_cache_size, work_mem and maintenance_work_mem sizing
  • Parallel-worker and I/O-concurrency tuning
  • Checkpoint tuning and forced-checkpoint pressure
  • Cluster memory-budget and cache-pressure analysis
  • Dangerous settings (e.g. fsync off) and JIT overhead

WAL & replication

The write-ahead log and standbys, before they threaten availability.

  • Inactive replication slots retaining dangerous WAL volume
  • WAL volume trending up against disk
  • Replication lag on standbys
  • Synchronous replication configured but no standby connected
  • Logical-replication apply pressure

Connections, locks & workload

Contention and saturation that shape tail latency.

  • Connection saturation against max_connections
  • Connection churn (pooling readiness)
  • Lock contention and deadlock rate
  • Long-running and idle-in-transaction sessions
  • Wait-event concentration and background-worker saturation

Schema & data model

Structural choices that age badly as data grows.

  • Large tables that are partitioning candidates; partition skew
  • Sequences approaching exhaustion
  • Extended statistics and statistics-target opportunities
  • TOAST update churn and fillfactor tuning
  • Per-object parameters drifting from cluster defaults

Security & privileges

Posture issues that develop quietly between reviews.

  • Row-Level Security not enabled where it should be, and policy gaps
  • Login-role posture (superuser sprawl, password policy)
  • Dangerous extension attack surface
  • Object and default privilege review

TimescaleDB

Professional+

Time-series operations, extension-aware.

  • Compression opportunities and compression backlog
  • Continuous-aggregate refresh falling behind
  • Chunk interval and chunk-count risk
  • Retention policy configured but not applying
  • Hypertable candidates and missing time indexes; failing jobs

Observability & capacity

The blind spots that hide everything else.

  • pg_stat_statements missing, or its cache evicting queries
  • Statistics reset mid-window (lost history)
  • Physical I/O and temp-file pressure
  • Tablespace / storage-placement opportunities

Examples are representative, not exhaustive. TimescaleDB coverage is available on Professional and above. Don't see the problem you care about? Ask us.