TimescaleDB
Hypertables, not ten thousand chunks
Standard Postgres monitoring sees chunks and misses the policies that manage them. DBExplore reads timescaledb_information views and alerts on the jobs, not the tables.
What goes wrong
Retention failures show up as a full disk
A retention policy that silently fails is discovered when storage hits 100 percent.
Refreshes that block reads
Continuous aggregate refresh takes an exclusive lock. When it lags, dashboards go stale and then go down.
Chunks larger than memory
A chunk over a quarter of RAM collapses ingest. The chunk interval was set once, years ago.
What DBExplore does about it
Compression and chunk health
Compression effectiveness per hypertable, chunk count and size, and chunk-size skew.
Continuous aggregates
Refresh lag against the watermark and background job latency.
Policy job outcomes
Retention success, job failures, and background worker usage against the configured maximum.
TimescaleDB-specific detection rules
With a remediation template to adjust chunk interval on approval.
TimescaleDB: questions we get first
Managed clouds?
Metric collection works everywhere TimescaleDB runs. Compression and retention actions apply only where the platform allows them, and DBExplore tells you when they do not.
Which versions?
Current TimescaleDB 2.x releases on the PostgreSQL versions they support.
How does the agent connect?
A container, Kubernetes deployment or sidecar, or native package next to your databases, using a read-only monitoring role over a small connection pool with short statement timeouts. No superuser.
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 TimescaleDB.
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.