Which signals does Datapace read for performance?

The workload statistics each engine exposes: query fingerprints with their calls, timing, and rows, plus instance metrics such as CPU and I/O, read with the scoped access your team agrees to. They sit on the same graph as the schema and its meaning.

Does the agent change the database?

It proposes. An index, a rewrite, or an upgrade is drafted with its evidence and waits for your approval; then it runs inside the window you agreed, and the result is verified against the evidence it was proposed on.

Does this replace monitoring?

It sits on top of it. Monitoring tells you a query is slow; Datapace tells you what it touches, what changed, and what to do about it, with the proposal ready to approve.

Database performance, proposed with the evidence and approved by your team

Performance work fails on context: the slow query is known, but not what calls it, what it touches, or what changed. Datapace keeps the workload signals (calls, mean and p95 time, rows, plan shape) on the same graph as the schema and its meaning, so the Performance agent can draft the index, the rewrite, or the upgrade with the evidence attached, and your team can approve it knowing what depends on the table.

Today. A slow query found from a complaint, fixed by whoever has time, with no record of what it touched or why the fix was safe.

With Datapace. The Performance agent flags the slow query, the missing index, and the overdue upgrade, each with the evidence. Your team approves the change.

What Datapace does here

Slow queries with their workload: Calls per day, mean and p95 time, rows scanned, and plan shape per query fingerprint, on the tables they touch, across the engines you run.
Index and rewrite proposals: The Performance agent drafts the index or the rewrite that changes the plan, with the evidence and the tables it affects, for your team to approve.
Regressions tied to their cause: When a query slows down, the graph shows what changed around it: a schema change, a data volume step, a new caller, so the fix targets the cause.
Overdue upgrades priced as risk: Engine versions past support, extensions behind, and instance families retired are surfaced per database with what depends on them.
Nothing runs on its own: Every proposal is approved by a person, executed inside the agreed window, and verified against the evidence, in the audit ledger.

Questions teams ask

Which signals does Datapace read for performance?: The workload statistics each engine exposes: query fingerprints with their calls, timing, and rows, plus instance metrics such as CPU and I/O, read with the scoped access your team agrees to. They sit on the same graph as the schema and its meaning.
Does the agent change the database?: It proposes. An index, a rewrite, or an upgrade is drafted with its evidence and waits for your approval; then it runs inside the window you agreed, and the result is verified against the evidence it was proposed on.
Does this replace monitoring?: It sits on top of it. Monitoring tells you a query is slow; Datapace tells you what it touches, what changed, and what to do about it, with the proposal ready to approve.

Go further

See this on your own data

Bring a use case. We will show you what Datapace reads on your live database, what your experts would confirm, and what the agents would propose first.

Book a call