· 5 min read
The pgvector index nobody measured
Vector search in Postgres degrades quietly. The index crosses RAM, the build runs on disk, recall decays with churn, and none of it raises an alert.
Read the post →
Early access · onboarding in batches
Postgres Autopilot. AI that runs your fleet, and earns the right to.
The AI-native control plane for Postgres fleets. AI agents detect, advise, and remediate across every engine you run, inside a fail-closed policy gate, with every action signed.
Or book a 30-minute demo, or read what a design-partner pilot involves first. No credit card, no drip campaign.
- Policy gate passed
- Signed ledger
- Human approval
remediation · example illustrativeAwaiting approval
Add index on orders(tenant_id, created_at)
seq scan → index scan · est. −94% query time · prod-eu-aurora-02
- Policy gate passed
- Fully reversible
- Inside off-peak window
Approve Reject
signed · ledger entry 0x8f3a…c41d · tamper-evident
$ dbexplore fleet status — every cluster · every engine · one console
- of detection rules
- 100s
- of remediation templates
- Dozens
- MCP tools
- 100+
- Postgres variants
- 20+
Runs wherever your Postgres runs
Observability tells you what happened. Autopilot handles what happens next, and proves it.
The problem
Nobody is watching the fleet.
Postgres teams stopped scaling with their fleets years ago. What replaced the DBA is a stack of consoles that each know one quarter of the truth.
Shift 1
Postgres won, and fragmented
It is the default database on every cloud, under a dozen brand names, inside operators and serverless platforms that did not exist five years ago. Each one hides its blind spots in a different console.
Shift 2
The operator ratio broke
Fleets grow every quarter. The people who understand them do not. The manual health check that used to be weekly is now never, and the pager knows it.
Shift 3
AI agents reached production
Assistants already hold database credentials. The question is no longer whether AI operates databases, but whether anything governs it when it does. Nothing does.
The bet
The AI that wins production is the AI that can be trusted with it.
The industry is racing to ship autonomous database agents. We think the race is being run in the wrong direction. Enterprises will not hand an agent a primary because it is confident. They will hand it one because every action is gated, approved, verified, and signed, and because the agent earned each step of autonomy on their own fleet. DBExplore is that governance layer, built on the deepest Postgres telemetry in the category.
Depth without action is a dashboard. Action without governance is an incident. We are the upper-right quadrant.
The alternatives
Four kinds of alternative, four different gaps.
Teams rarely compare us with one competitor. They compare us with a category they have already half-adopted, and each one fails in a structurally different place.
| The alternative | What it is good at | Where it structurally stops |
|---|---|---|
| Cloud consoles | Performance Insights, Cloud SQL Insights, Azure Monitor. Free, already switched on, and closest to the metal of the engine they ship with. | One cloud, one engine, one account. Nobody sees the fleet, and no console will ever act on the cluster next door. |
| General observability platforms | Your metrics, logs and traces in one place, with the database as one more service among hundreds. | Database internals are a shallow integration. Bloat, wraparound runway, lock trees and plan regressions are not in the model, and the bill grows with ingestion rather than with value. |
| Postgres monitoring tools | Real depth. Query statistics, plans, indexes, vacuum. Built by people who know the engine. | They stop at advice, deliberately. You still carry every fix to production by hand at three in the morning, and nothing records who decided what. |
| AI database assistants | A model with database access that will happily suggest, and sometimes run, a fix. | No gate, no earned autonomy, no signed record. Confidence is not a control, and a security team cannot sign off on a tool whose worst case is unbounded. |
Built for the agentic era
AI at every layer. A mechanism behind every claim.
We use the words everyone uses. The difference is that each one on this page names the thing that makes it true.
AI-native detection
Signatures for the failures operators can name, statistical models for the ones they cannot, tuned per engine so Aurora noise is never CockroachDB signal.
An advisor that shows its evidence
Every recommendation carries the plan before, the plan after, the cost delta, and the writes it will slow. Explainable by design, because DBAs turn off what they cannot argue with.
Agentic remediation, governed
Agents propose fixes with dry-runs attached. A fail-closed policy gate decides. Humans approve. The agent executes, verifies, and signs the proof.
MCP-native from day one
Claude, Cursor, and your own agents investigate and act through the same gate a human hits. AI gets a governed path into production, never a back door.
Autonomy that is earned
A four-rung ladder from observe to auto-apply. Actions climb only on a measured precision record on your fleet. Destructive operations have no rung.
Proof for the board and the auditor
Every observation, decision, and action, by human or agent, lands in a signed, tamper-evident ledger. AI operations become auditable operations.
How it works
Observe, detect, advise, act, prove.
An autopilot watches the whole aircraft, handles the routine, asks you for the critical, and logs everything. DBExplore does the same for a Postgres fleet.
- 01
Observe
One agent per tenant collects from pg_stat views, cloud APIs, HA orchestrators, and poolers.
- 02
Detect
Signatures and models turn raw telemetry into deduplicated, engine-aware anomalies.
- 03
Advise
The advisor proposes a fix with its dry-run, its cost, and its rollback.
- 04
Act
The policy gate evaluates. A human approves. The action runs and verifies itself.
- 05
Prove
The signed ledger records what was seen, decided, and done, for as long as your auditors need it.
The agent team
Four roles, separated on purpose.
One model doing everything is one prompt away from a bad afternoon. DBExplore splits the work the way a database team does, and only the last role can touch anything.
- 01
Observers
Watch the fleet continuously and turn raw telemetry into named, deduplicated conditions. They never propose anything.
Read only
- 02
Analysts
Take a condition and work out why. Correlate across the cluster, the topology and recent change, and produce a root cause with the evidence attached.
Read only
- 03
Advisors
Turn a cause into a specific, costed recommendation, with the plan before, the plan after, and what it will slow down.
Proposes
- 04
Remediators
Carry an approved recommendation through the gate, execute the declared template, verify against live state, and sign the result.
Acts, under policy
Each role is specialised per signal family rather than general-purpose, so the agent reasoning about replication lag is not the same one reasoning about vacuum. A finding has to survive the handoff between roles, which is a cheaper filter than asking one model to check its own work.
Co-learning
It gets better on your fleet, without your data leaving it.
A detection library that ships the same thresholds to everyone is wrong for almost everyone. DBExplore learns from what your team approves, rejects and rolls back, and tunes itself to your fleet.
Every outcome is a label
Approved, rejected, rolled back, ignored. Each one is a signal about whether that recommendation was worth making on your fleet.
Calibrated against your baselines
Thresholds that fire correctly on a busy payments cluster are wrong on a quiet reporting replica. They are learned per cluster, not shipped as one number.
Ranked by what you actually act on
Advice you consistently skip drops down the queue. Advice you consistently take moves up, and eventually becomes a candidate for one-click.
Rolled out in the shade first
Every loop starts shadowed, comparing itself against what actually happened without touching anything. Then canary. Then on, per tenant, by your choice.
Your learning stays yours
The model starts from a general prior so a new cluster is useful on day one, then everything it learns about your fleet stays scoped to your tenant. Training data never crosses a tenant boundary. Nobody else's fleet teaches on your incidents, and yours does not teach on theirs.
Nothing is switched on for you
Each loop is independently flagged per tenant and starts in shadow mode, where it makes predictions and records whether it would have been right, while changing nothing. You promote it when the record justifies it. This is the same discipline the autonomy ladder uses, applied to learning rather than to acting.
The platform
Observability first. Automation when it has earned it.
Everything a database team needs to see across a heterogeneous fleet, and a governed path from insight to action. This is the product behind the bet.
Fleet observability
Active session history, plans, locks, vacuum, replication and HA, poolers, drift, and security posture, normalized across every engine.
Anomaly detection
Hundreds of detection rules tuned per engine, with statistical models for the failures nobody has a runbook for yet.
AI advisor
Index, query, and schema recommendations that show the plan before, the plan after, and the writes they will slow down.
Action plane
Dozens of remediation templates that dry-run first, execute on approval, and verify against the live system afterwards.
Fail-closed policy gate
Policy-as-code decides before anything mutates. Deny, timeout, or unreachable all mean no. Disruptive actions need more than one human, always.
Signed trust ledger
Every observation, decision, and action lands in a signed, chain-hashed ledger your auditors can verify without translation.
Topology discovery
Seven dimensions per cluster: engine, HA orchestrator, pooler, backup, replication, extensions and whatever is already watching it. Probed, not asked.
Earned autonomy
Autonomy is earned through measurement, never a settings toggle.
Every action carries a rung on the ladder. It climbs only after a measured precision record on your fleet, per action class, per tenant. Destructive operations on a primary have no rung at all.
- rung 0
Observe
Detect and explain. No action offered.
- rung 1
Recommend
A specific action with its dry-run and predicted effect. You decide and run it.
- rung 2
One-click
Pre-validated, rollback pre-computed, executable in one gesture. You approve.
- rung 3
Auto-apply
Runs under policy, observes the result, rolls back on regression. You audit.
Who it is for
Built for teams running a fleet, not a database.
- Mid-market to enterprise teams with a hundred or more engineers, or a hundred or more Postgres instances.
- Cloud-native or hybrid fleets across RDS, Aurora, Cloud SQL, Azure, Neon, Supabase, and self-hosted Patroni or Kubernetes operators.
- A DBA or DBRE function that answers to platform engineering, with auditors asking about data residency.
From the blog
How we build it, in enough detail to argue with.
· 5 min read
Aurora's writer endpoint can lie to you
CloudWatch measures instances. Your application talks to endpoints. For the minute those disagree, every instance metric looks healthy while writes fail.
Read the post →
· 5 min read
PostgreSQL 18 moved the WAL I/O counters
pg_stat_wal lost its write and sync columns to pg_stat_io in 18. Nothing errors. The numbers just stop arriving, and most monitoring never notices.
Read the post →
Questions teams ask before a pilot
How does DBExplore connect to my databases?
A small agent runs next to your databases as a container, a Kubernetes deployment or sidecar, or a native package. It connects with a monitoring role, never superuser, through a small read-only connection pool with short statement timeouts. Cloud metrics come from your cloud provider's monitoring APIs through the same agent.
What data leaves my database?
Metrics, catalog metadata, execution plans, and query text with literals scrubbed by the agent before anything is sent. Parameter capture is off by default. Row data never leaves. Query text is classified confidential, stored encrypted, and visible only to your tenant.
Can the AI run anything on production without a human?
Not by default. Every tenant starts at approve, so DBExplore proposes and a person confirms. Cluster-wide and disruptive actions always need two approvers. An action class moves to one-click or auto-apply only after it has earned a measured precision record on your fleet, and every run passes a fail-closed policy gate first.
Which Postgres versions and engines are supported?
All currently supported PostgreSQL major versions on self-hosted and Kubernetes, and the versions each cloud offers on RDS, Aurora, Cloud SQL, AlloyDB, Azure Database for PostgreSQL, Neon, Supabase, TimescaleDB, and Citus. CockroachDB and YugabyteDB are covered with their own signals, because their planners and storage are not Postgres.
Is it SaaS or self-hosted?
Both. The control plane runs as multi-tenant SaaS with a region you choose, or self-hosted from a signed Helm chart. EU data residency is available through a dedicated EU-region deployment.
How is early access priced?
Early access runs as a ninety-day pilot on up to three databases with a capped AI spend. We agree the scope on the first call. No credit card, no auto-renew.
Put every Postgres you run on autopilot.
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.