Database observability: what your provider should show you
TL;DR: monitoring tells you a threshold was crossed. Observability lets you ask a question nobody anticipated. The single sharpest test is restore time: measured, dated, and available without a ticket.
Ask your managed database provider a simple question: what is our current restore time for the production cluster, measured on the last real test, not estimated from the backup size?
One kind sends you a number and the date it was measured. The other kind opens a ticket.
This article is about the gap between those two answers, and about the specific artifacts a serious operator can produce on demand.
Green dashboards are not evidence
The most expensive database failures are the ones that develop for weeks in a system where nobody was looking at the right signal, and where the person who could have looked did not have access.
When telemetry lives only on the provider's side of the boundary, silence and health look identical from where you sit. You are not being told everything is fine. You are being told nothing, and reading it as fine.
Apache Cassandra is a good example, because its failure mode is famously quiet. It ships with no built-in repair scheduling, and mistuned compaction and tombstone buildup degrade performance silently rather than loudly. An unattended cluster does not fall over. It rots, for weeks, while every uptime check stays green. PostgreSQL and MySQL have their own versions: bloat, autovacuum drift, and replication lag that stays inside tolerance right up until it does not.
An uptime percentage does not see any of this. It is the wrong instrument for the question.
Monitoring and observability are not the same purchase
Monitoring answers questions you thought of in advance. You defined a threshold, something crossed it, an alert fired. It is necessary and it is cheap, which is why every provider has it and why every provider's slide deck shows it.
Observability is the property of being able to answer a question you did not anticipate, from data you are already collecting, without deploying anything new. "Why were writes slow for eleven minutes on Tuesday between 14:20 and 14:31, and was it the same cause as the Thursday before?" is an observability question. No dashboard was built for it in advance. Either the data is there and you can go get it, or it is not and you are guessing.
A provider running on monitoring alone can tell you an incident happened. A provider running on observability can tell you why, and therefore whether it will happen again. That is the same distinction that separates ticket-ops from reliability engineering, viewed through the data layer.
The seven artifacts your provider should be able to produce
Not "would be nice to have." These are the things a competent operator already has, because they need them to do the work.
1. Your own dashboards, in your own accounts, without asking
Read access to live metrics and logs for your own systems should be a property of the arrangement, not a favor granted per request. Where deployments sit inside your cloud accounts, this falls out naturally: the data is already yours and the provider is operating inside your boundary rather than behind their own.
Test it this way. Can an engineer on your team pull up production database metrics right now, without messaging anyone?
2. Replication lag, with a defined threshold and a live alert
Replication lag is the single most useful leading indicator on the data layer, because it converts directly into both performance risk and data loss exposure. A practitioner-grade standard for migration and steady-state work is holding lag under five seconds, with checksum-based validation that the replica actually matches the primary.
Two questions, not one. What is the threshold, and what happens automatically when it is crossed? A threshold with no automated action attached is a number on a screen.
3. Restore time, measured and dated
Backups are not a recovery capability. Tested restores are.
The artifact you want is a date, a measured duration, and the environment the test ran in. "We take nightly snapshots" is a description of a cron job. "We restored the 2 TB production cluster into an isolated environment on July 22 and reached full consistency in 47 minutes" is a recovery capability, and only one of those two sentences is worth anything.
4. Backup verification evidence, not backup success logs
A backup job that exits zero has told you a file was written. It has not told you the file is restorable, not corrupt, and complete. Verification means a restore actually happened and the data was checked.
Ask how often verification runs, what it validates, and where the evidence lives. If the answer is that the backup dashboard is green, you have a success log, not verification.
5. Slow query and plan regression history
Query performance degrades gradually, usually because a plan changed after a data volume crossed a threshold or statistics went stale. The operator should hold a history of slow queries and execution plans over time, so that "the app got slower this quarter" becomes an answerable question rather than a debate.
This is also where the difference between a service and a partnership becomes visible. An operator with plan history brings you an index recommendation you did not ask for. A queue waits for a ticket that says the app is slow, which nobody opens until it is bad enough to be political. That specific test, when did your provider last bring you something you did not ask for, is sign four of a provider you should be evaluating.
6. Capacity runway with a date attached
Disk, connections, memory headroom, IOPS. Not "we monitor capacity," but a projected date at current growth rate for each constraint. Capacity incidents are the most preventable class of database failure and the most embarrassing, because the data needed to predict them was sitting in the metrics for months.
7. Engine-specific degradation signals
Generic infrastructure monitoring catches CPU, memory, and disk. It does not catch tombstone ratios, compaction backlog, repair status, autovacuum lag, bloat, or index drift. Those are the signals that matter on the data layer and they differ per engine.
A provider running one dashboard template across every engine they operate is telling you something about how deep their expertise goes. Ask what they monitor on Cassandra specifically that they do not monitor on PostgreSQL. A specific answer takes about twenty seconds and cannot be faked.
Why the observability question is really a cost question
Waiting is the expensive part of an outage. The failure takes seconds. What takes hours is detection with thin instrumentation, escalation into a queue, diagnosis by an engineer who has never seen the environment, and a restore nobody rehearsed.
The money follows that clock. The ITIC 2024 Hourly Cost of Downtime study puts hourly downtime above $300,000 for more than 90% of mid-size and large enterprises, with 41% of respondents reporting $1M to $5M or more per hour. Every artifact on the list above removes minutes from the detection and diagnosis phases, which is the only part of that clock a provider actually controls.
It is also worth putting next to your SLA. A 99.99% availability commitment allows roughly 4.4 minutes of downtime per month. A detection gap of twenty minutes means the SLA was structurally unachievable before anyone touched a keyboard, which is the kind of thing SLA fine print tends to obscure.
The uncomfortable part: visibility is a commercial choice
There is a reason some providers keep telemetry on their side of the wall. A customer who can see their own environment can see the provider's work, or the absence of it. They can benchmark. They can tell whether an incident was handled well. They can leave and take their dashboards with them.
Visibility is a decision about whether the provider wants to be evaluated continuously. That is the same logic that governs where your data physically lives and how hard it is to leave: an operator with nothing to hide structurally has no reason to hold your telemetry hostage, and an operator that does hold it has told you something.
FAQ
What is database observability?
Database observability is the ability to answer questions about a database's behavior that nobody anticipated in advance, using data already being collected. It goes beyond monitoring, which alerts when a predefined threshold is crossed. In a managed service context it means the customer can investigate their own system's behavior directly, rather than requesting a report from the provider.
What is the difference between database monitoring and observability?
Monitoring answers predefined questions: is the disk above 80%, is the node up. Observability answers new questions after the fact: why were writes slow for eleven minutes on Tuesday, and was it the same cause as last week. Monitoring is a set of alerts; observability is a property of the data you keep and who can query it.
What should a managed database provider give me visibility into?
Live metrics and logs for your own systems without a request, replication lag with a defined threshold and automated action, measured and dated restore times, backup verification evidence rather than success logs, slow query and execution plan history, capacity runway projections per constraint, and engine-specific degradation signals such as compaction backlog or autovacuum lag.
How do I test whether my provider's monitoring is real?
Ask for the measured restore time of your largest production cluster, the date that test ran, and the environment it ran in. A provider that rehearses recovery answers within a day from existing records. A provider that does not will offer an estimate derived from data volume, or open a ticket.
Does an uptime SLA prove my databases are healthy?
No. Availability measures whether the service responded, not whether it is degrading. Slow-developing problems such as tombstone buildup, index bloat, or a plan regression can run for weeks while every uptime check passes. Availability and health are different measurements, and only one of them is usually contractual.
