Monitoring managed PostgreSQL

No single layer is a complete diagnosis. A query-statistics reset, provider compute restart, scale-to-zero wake, or pooler queue can change what another layer appears to show.

This read-only query provides a bounded database baseline that works across supported PostgreSQL versions. It does not expose SQL text or application data.

SELECT
  clock_timestamp() AS observed_at,
  current_database() AS database_name,
  pg_database_size(current_database()) AS database_bytes,
  numbackends AS current_backends,
  xact_commit,
  xact_rollback,
  blks_read,
  blks_hit,
  temp_files,
  temp_bytes,
  deadlocks,
  stats_reset
FROM pg_stat_database
WHERE datname = current_database();

• Record timestamps, time zones, database or branch identity, provider region, and collection source.
• Preserve raw counters and reset timestamps before calculating rates or ratios.
• Label current gauges, cumulative counters, interval deltas, and billing-period totals differently.
• Track missing values as unavailable rather than zero.
• Correlate deployments, migrations, scheduled jobs, maintenance, scaling events, and incidents with the same timeline.

Neon's compute monitoring includes platform-specific signals such as compute behavior, Local File Cache, and working-set information, while its APIs expose provider-defined project and consumption fields. Supabase Reports cover database resource and pooler signals, and its Metrics API exposes a broader Prometheus-compatible set. Availability, retention, and definitions can differ by provider feature and plan, so use the current console and documentation for the project.

Core PostgreSQL statistics remain valuable on both platforms, but they do not replace provider status, logs, backup visibility, pooler metrics, or billing definitions.

• Alert on user impact or sustained capacity pressure, not every short spike.
• Include the metric definition, observation window, threshold, and runbook in the alert.
• Use separate warning and urgent levels when a capacity limit is known.
• Treat missing or stale telemetry as its own condition rather than a healthy zero.
• Test routing and recovery notifications; an alert is incomplete if nobody can act on it.

• Logical database size, provider disk, object storage, backups, and billed storage are not interchangeable.
• PostgreSQL block reads do not equal provider disk IOPS.
• A connection count behind a pooler does not show every client or queued request.
• A cumulative query leader is not necessarily the current incident cause.
• No alert does not prove health when a collector is stale, unauthorized, or missing a metric.

DatabaseMeter combines supported Neon and Supabase project usage with optional read-only PostgreSQL telemetry. Depending on the connected provider and available permissions, it can preserve storage and growth observations, compatible compute or transfer usage, connection and activity summaries, table signals, cache counters, and normalized query-fingerprint deltas.

Collection source and missing data remain explicit. DatabaseMeter does not replace provider-native CPU, memory, IOPS, pooler, backup, log, incident, or billing views, and direct PostgreSQL collection can wake a suspended Neon compute. Use the provider console alongside DatabaseMeter when diagnosing service behavior.