Neon
Monitoring that never wakes a sleeping compute
Neon separates compute from storage, so standard metrics miss the pageserver and safekeeper layer entirely. DBExplore reads Neon's own signals and scrapes only when your compute is already awake.
What goes wrong
Monitoring that costs money
A naive scrape wakes an idle endpoint and bills you for compute you did not use.
A cache you cannot see
The local file cache decides whether a query touches remote storage. Its hit rate is the real performance metric and it is not in pg_stat_bgwriter.
Branch sprawl
Branches are cheap to create and easy to forget. Thirty-day-old branches accumulate storage and confusion.
What DBExplore does about it
Zero-wake collection
The collector checks compute state first and scrapes only active endpoints. Wake attempts are recorded as their own events.
Cache and durable-commit lag
Local cache effectiveness and safekeeper lag as the signals that actually predict Neon latency.
Compute and storage economics
Active time, autoscaling ceiling proximity, startup time, and logical versus physical storage size.
Branch hygiene
Branch age and stale-branch detection, with branch-level retention snapshots.
Neon: questions we get first
Do you support Neon read replicas?
Yes, with replica lag tracked per read replica compute.
Index what-if analysis?
Supported once the what-if extension is enabled on the project. The advisor tells you when it is missing.
What leaves the database?
Metrics, catalog metadata, execution plans, and query text with literals scrubbed on the agent before it is sent. Parameter capture is off by default. Row data never leaves.
Can DBExplore change anything without approval?
Not by default. Every tenant starts at approve. Disruptive actions always need two approvers, and every mutating action passes a fail-closed policy gate first.
Run DBExplore on your Neon.
We onboard teams in small batches. Tell us about your fleet and we will reach out when a seat opens. One email, no drip campaign.