Monitor PostgreSQL directly without inventing provider data.

PostgreSQL keeps running statistics about itself. Every table scan, index lookup, connection, and cached page is counted internally and exposed through system views and catalog tables. Monitoring is nothing more exotic than reading those counters on a schedule and comparing today's values with last week's.

This matters because a database rarely fails suddenly. It drifts. A table quietly triples in size, an index stops being used, dead rows pile up faster than autovacuum removes them, connections accumulate. Each change is invisible on any single day and obvious across a month — but only if something recorded the history.

You do not need to be a database administrator to benefit from this. You need four habits: know how big things are, know how fast they are growing, know what is running, and know when something changed.

PostgreSQL exposes hundreds of metrics. For a novice running a small application database, a short list explains most real problems.

• Database and table size. Start here, because everything else becomes easier to interpret once you know where the bytes are. See how to check PostgreSQL database size.
• Index size. Indexes make reads fast and writes slower, and they consume real space. Unused indexes are pure cost — measuring index size shows how to find them.
• Dead tuples and autovacuum. PostgreSQL does not overwrite rows in place; updates and deletes leave dead versions that autovacuum reclaims later. When it falls behind, tables bloat. Read dead tuples and autovacuum.
• Sequential scans. A large table being read end to end on every query usually means a missing index — see sequential scans.
• Connections and session state. pg_stat_activity shows what is connected right now, and idle in transaction covers the state that blocks cleanup and holds locks.
• Cache hit behavior. Whether reads are served from memory or disk changes performance dramatically — see cache and I/O statistics.
• Aggregate query workload. With pg_stat_statements enabled, you can see which query shapes consume the most total time, which is almost never the query you would have guessed.

This is the question new users ask most often, and the answer is rarely "you have too many rows." PostgreSQL's storage model means space is consumed by more than the data you think you inserted.

Updates and deletes create dead row versions that occupy space until autovacuum reclaims it, and reclaimed space is usually reused rather than returned to the operating system. Indexes grow alongside their tables and can become bloated on their own. Write-ahead log files, temporary files from large sorts, and toasted large values all take room. Append-only tables like logs, events, sessions, and webhook payloads grow forever unless something deletes from them.

The practical approach is to identify the largest relations first, then ask whether that specific object should be that large. Why a PostgreSQL database keeps growing works through the causes in order, and the database growth calculator projects where a current trend leads.

Most PostgreSQL statistics are cumulative counters that increase since the last reset. A single reading tells you almost nothing; the difference between two readings is the useful number. Comparing across a statistics reset or a server restart produces nonsense, which is why DatabaseMeter only compares values across intervals it knows are compatible.

Ratios deserve the same skepticism. A high cache hit ratio does not prove the database is healthy, and a table with many sequential scans is not automatically a problem if it holds twenty rows. Context — size, frequency, and trend together — is what turns a metric into a conclusion.

The right way to connect any monitoring tool to PostgreSQL is a dedicated login that can read statistics and nothing else. DatabaseMeter generates copy-ready SQL for exactly that: a database-specific role with no superuser, no database or role creation, no replication, and no ability to bypass row-level security. It requests no permission to insert, update, delete, or alter your application tables.

Sessions default to read-only with bounded statement and lock timeouts, so a monitoring query cannot hang and cannot hold a lock that blocks your application. SQL text is never selected or stored — only fingerprints and aggregate counters. The password is encrypted server-side and is not displayed again after you save it.

Direct connections require a publicly reachable endpoint and certificate-verified TLS. Private, loopback, link-local, and cloud metadata addresses are rejected, insecure TLS modes are unsupported, and destination validation runs again before every scheduled collection rather than only at setup. The security model documents each control.

If you would rather see the value before creating an account, two public tools run without one. The PostgreSQL health check reviews size, connection utilization, autovacuum pressure, and scan behavior in a single pass and explains each observation in plain language. The pg_stat_statements analyzer ranks query shapes by total consumed time so you can see where the load really is.

For structured reading, the PostgreSQL Learn center covers each concept with safe, copy-ready SQL and notes on how to interpret what comes back — including the interpretations that commonly go wrong.