Quick Answer
Database monitoring is the continuous tracking of a database's health, performance, and resource consumption, covering metrics like query latency, throughput, connections, and replication lag. In the AI era, it has expanded to include a fifth dimension: spend. Modern teams monitor not just whether the database is fast, but whether the workload it serves is worth what it costs to run.
In May 2025, an engineer named Bohan Zhang stood up at PGConf.dev in Montreal and broke every scaling rule in the book. OpenAI, as he later detailed in an OpenAI engineering post, runs the backbone of ChatGPT on a single primary PostgreSQL instance with nearly 50 read replicas. No sharding. One writer, serving 800 million people.
The talk, and the engineering post OpenAI published in January 2026, became one of the most discussed database stories in years, and for good reason. Over a single year, OpenAI’s PostgreSQL load grew by more than 10x. Postgres overload had already caused several ChatGPT incidents. The whole thing runs on managed Azure Database for PostgreSQL flexible server, handling millions of queries per second.
Here’s the part of that story almost nobody talks about: every replica, every managed instance hour, every gigabyte of replicated storage lands on a bill. When your database layer scales 10x in a year, so does the line item behind it. Engineers see latency. Somebody in finance sees something else, usually weeks later.
That gap, between what your monitoring shows and what your CFO eventually finds, is what this guide is really about. We’ll cover what to track, which tools do it well, and the one metric almost no dashboard surfaces: what each database workload actually costs, and whether it’s earning its keep.
What is database monitoring?
Database monitoring is the practice of continuously collecting, analyzing, and alerting on the signals a database emits: query performance, resource utilization, availability, replication health, and errors. The goal is simple. Catch problems before users do, and understand what normal looks like so anomalies stand out immediately.
A modern database monitoring system typically works through lightweight agents or native APIs that pull telemetry from the database engine. That telemetry ships to a central platform, where it becomes dashboards, alerts, and baselines. Some teams build this stack from open source components. Most teams, once they price the maintenance burden honestly, buy it.
You’ll also hear the term database observability, and the two are worth separating. Monitoring tells you that something is wrong: latency spiked at 2:14 p.m. Observability tells you why: a query plan regression on one table, triggered by yesterday’s deploy. Monitoring watches known signals. Observability lets you interrogate unknown ones.
That distinction matters more now than it did five years ago, because the thing generating unknown signals has fundamentally changed. AI workloads behave nothing like the CRUD applications most monitoring playbooks were written for, and they arrived fast. So let’s start there.
Report
Finance needs to prove AI’s return: CloudZero report
260 senior finance leaders (more than half CFOs) told us why the speed of seeing AI spend, not the size of it, separates who pulls ahead on AI from who gets burned.
How has AI changed database monitoring?
More than any shift since the move to the cloud itself. Three changes stand out, and each one rewrites part of the monitoring playbook, starting with the sheer shape of the load that modern databases now carry every single day.
The workloads got heavier and stranger. AI applications hammer databases in bursts: embedding writes during ingestion, massive read fan-out during retrieval, and long analytical queries feeding training pipelines. OpenAI’s 10x load growth in one year is the extreme case, but the pattern appears everywhere teams bolt a RAG pipeline onto production data.
Entirely new database categories appeared. Vector databases barely registered in 2022. The global vector database market is projected to grow from $3.65 billion in 2026 to $21.45 billion by 2036, a 19.3% compound annual growth rate. Their key metrics, like index build time and embedding storage growth, don’t exist in traditional tooling.
Database spend became AI spend. When Postgres stores your AI product’s conversation history, your vector store feeds retrieval, and your warehouse trains the next model, the database bill stops being an infrastructure footnote. It becomes a core input to AI ROI. And most companies cannot see it clearly.
In CloudZero’s 2026 survey of 260 finance leaders, 50% said they wait days, or until the bill arrives, to see spend data. Only 16% have real-time visibility. Engineering watches database performance second by second. Half of finance learns what those databases cost after the month closes.
Same infrastructure, two completely different clocks. Closing that gap starts with agreeing on what belongs on the dashboard in the first place. So what should you actually track? Start with the five metric families below.
Which database monitoring metrics matter most?
Every database engine exposes hundreds of counters. Effective database monitoring metrics boil down to five families, and the fifth is the one most teams skip. Together they answer two questions: is the database healthy, and is the workload it serves worth the money behind it?
- Query performance. Latency (p50, p95, p99), slow query counts, and query plan changes. This is the family your users feel directly. A p99 that creeps from 20ms to 200ms is a fire alarm, even when the averages still look perfectly fine.
- Throughput. Queries per second, transactions per second, and rows read versus rows returned. A query reading a million rows to return ten is a full table scan begging for an index. It also burns compute you’re paying for by the hour.
- Resource utilization. CPU, memory, disk I/O, and storage growth. Watch the trend lines, not the snapshots. Storage growing 8% a month doubles in under a year, and on managed services, the storage charge doubles right along with it.
- Availability and replication. Uptime, failover readiness, and replication lag. OpenAI’s team obsesses over lag for a concrete reason: dozens of replicas serving stale reads would quietly corrupt the experience for hundreds of millions of users before any alert fired.
- Cost per workload. The family missing from almost every default dashboard: what each database, workload, and customer actually costs. Not the total bill, but the unit economics. We covered the mechanics in our guide to database cost management, and it turns monitoring data into business decisions.
If performance metrics answer “is it healthy?”, cost metrics answer “is it worth it?”. You need both. That brings us to the tools, because very few of them even attempt to answer the second question.
What are the best database monitoring tools?
The database monitoring tools market splits into three camps: full observability platforms, database specialists, and native cloud services. There’s no single winner, because the best database monitoring tools for a SQL Server shop, a Snowflake-heavy data team, and an AI startup are three different answers.
| Tool | Best for | Standout strength | Pricing model | Cost visibility |
|---|---|---|---|---|
| Datadog | Cloud-native fleets | Query-level insight across engines | Per host + ingestion | Performance only |
| SolarWinds DPA | SQL Server and Oracle shops | Wait-time analysis | Per instance | Performance only |
| Dynatrace | Large enterprises | Automatic dependency mapping | Consumption-based | Performance only |
| New Relic | Full-stack teams | Database views inside APM context | Usage-based | Performance only |
| ManageEngine | Mid-market breadth | Widest engine coverage | Per monitor | Performance only |
| Site24x7 | Small teams | All-in-one simplicity | Tiered subscription | Performance only |
| Prometheus + Grafana | Build-it-yourself teams | Free, endlessly flexible | Open source | Performance only |
| CloudWatch / Azure Monitor / Cloud Monitoring | Managed cloud databases | Native, zero-setup metrics | Pay per metric and log | Performance only |
| CloudZero | Engineering + finance together | Cost per workload, tenant, and feature | Platform | Spend by design |
Read that last column top to bottom and you’ll see the market’s blind spot in one glance. Now the honest read on each option, including where every one of them is strong and where it isn’t.
- Datadog. Datadog database monitoring is the most complete offering among the big observability platforms, with deep query-level insights for Postgres, MySQL, SQL Server, and Oracle. The trade-off is the bill: per-host pricing plus ingestion charges means monitoring costs scale alongside the databases being monitored, sometimes surprisingly fast.
- SolarWinds Database Performance Analyzer. A longtime favorite of DBAs, especially in SQL Server shops. SolarWinds database monitoring is built around wait-time analysis, genuinely excellent for query tuning and root-causing slow statements. It’s noticeably less compelling for cloud-native and NoSQL estates, where its coverage thins out.
- Dynatrace. Dynatrace database monitoring rides on strong automatic dependency mapping, so it shines when you need to trace a slow API call down to the exact database statement behind it. The AI-driven root cause analysis is real. The platform is priced and packaged for large enterprises.
- New Relic. New Relic database monitoring lives inside its APM product, which is the point: query performance appears in the context of the application calling it. Teams already on New Relic get database visibility nearly free. Teams that aren’t rarely adopt it for databases alone.
- ManageEngine Applications Manager. Broad engine coverage at a mid-market price point, spanning relational, NoSQL, and cloud databases in one product. The breadth is the pitch. You give up some per-engine depth compared with the dedicated specialists above.
- Site24x7. A solid all-in-one for smaller teams that want infrastructure, application, and database performance monitoring in one place. You get respectable coverage without a platform-sized contract, which is exactly the right trade for many mid-sized environments.
- Prometheus + Grafana. The definitive open source pick. Exporters exist for nearly every database engine, and the software costs nothing. The engineering time to build, tune, and maintain it does not. That is the math to run before choosing this route.
- Native cloud tools: CloudWatch, Azure Monitor, and Cloud Monitoring. The default starting point for managed databases, and genuinely capable for RDS and Aurora. Watch the meter, though. As our CloudWatch pricing breakdown details, custom metrics, dashboards, and log ingestion each carry charges that compound as databases multiply.
- CloudZero. Not a performance monitor, and we won’t pretend otherwise. CloudZero monitors the dimension the tools above don’t: what every database workload costs, unified across engines and clouds, tied to the products and customers those databases serve. More on exactly how that works at the end.
Every tool above assumes you already know which database you’re running. In the cloud, that choice and the monitoring approach are tangled together, because on managed platforms the performance signals and the spend signals are the same numbers. Here’s how that plays out per platform.
How do you monitor cloud databases?
Cloud database monitoring differs from on-premises monitoring in one fundamental way: the provider handles the plumbing, and you pay for exactly what the metrics show you’re using. Every performance signal doubles as a spend signal. That changes what deserves your attention on each major platform.
- Amazon RDS and Aurora. CloudWatch provides the core metrics free; Performance Insights adds query-level depth for a fee. The monitoring insight that matters most financially is right-sizing, because RDS bills by instance hour and the gap between classes is steep. A database idling at 20% CPU is a downsize request nobody’s reading.
- Amazon DynamoDB. Watch consumed versus provisioned capacity units, plus throttling events. The DynamoDB pricing model charges for provisioned capacity whether you use it or not. The gap between those two lines on your dashboard is pure, quantifiable waste.
- Amazon Redshift. Query queue times and disk utilization tell you when a cluster is undersized. Low concurrency tells you when it’s oversized. Redshift’s pricing rewards the teams that watch both signals and act on them quarterly.
- Snowflake. The metric that matters is credit consumption per warehouse, per query, per team. Snowflake’s elasticity is both superpower and budget risk: a warehouse on auto-resume with a runaway query can burn a month’s budget over a weekend. Our guides to what Snowflake is and Snowflake pricing cover the mechanics.
- MongoDB Atlas. MongoDB database monitoring on Atlas centers on cluster tier utilization and auto-scaling events. Atlas serves more than 63,900 customers, and roughly 75% of the Fortune 100 rely on MongoDB, on a consumption model where every scaling event is a pricing event. Our MongoDB pricing analysis goes deep on it.
- Databricks. Track DBU consumption by job and by cluster. Idle interactive clusters are the classic leak, and Databricks pricing makes them expensive company to keep around. An auto-termination policy is the cheapest monitoring alert you’ll ever configure.
- Relational engines: SQL Server, Oracle, and MySQL. The habits carry across vendors, but each engine has its own levers. SQL Server leans on wait statistics and blocking analysis, and Azure SQL builds those views into the portal natively. Oracle runs mainly through Enterprise Manager. MySQL pairs the slow query log with Performance Schema.
Notice the theme across all seven platform families. The best performance practice and the best spend practice are the same practice: watch utilization, catch anomalies early, right-size continuously. Which raises the obvious question of how disciplined teams actually operationalize that, day to day.
What are database monitoring best practices?
Six database monitoring best practices separate teams that catch problems early from teams that read about them in incident reports. None require exotic tooling. All of them require deciding, in advance, what deserves a page, what deserves a ticket, and what deserves a dollar figure.
- Baseline before you alert. You can’t spot abnormal without knowing normal. Collect two to four weeks of metrics before setting thresholds, then alert on deviation from baseline rather than absolute values. Absolute thresholds age badly as workloads grow and seasons shift.
- Page on symptoms users feel, ticket the rest. Alert fatigue kills monitoring programs faster than missing metrics ever will. Page on p99 latency, error rates, and replication lag. Route everything else to tickets and dashboards, where it informs without exhausting anyone.
- Watch trends, not just spikes. The expensive failures are slow: storage creeping toward full, connections climbing toward limits, spend growing 6% month over month. Review trend dashboards weekly, the same cadence we recommend across cloud monitoring tools generally.
- Monitor the query layer, not just the host. Host CPU at 90% is a symptom. The unindexed query causing it is the diagnosis. Tools that stop at infrastructure metrics leave your team troubleshooting blind, one deploy away from the same incident repeating.
- Treat AI workloads as first-class tenants. Give embedding pipelines, retrieval workloads, and training queries their own dashboards and budgets. They grow faster than everything else and compete for the same resources, the pattern we see constantly in Kubernetes cost monitoring too.
- Put a dollar figure next to every dashboard. This practice changes conversations. When the replication view shows six replicas and the spend view shows the monthly cost of each, “do we need six?” becomes an answerable question instead of a philosophical one.
That last practice deserves its own section, because it’s where most organizations’ monitoring stops short, and it’s also, not coincidentally, where the money is. Before we get to the tooling that closes the gap, it’s worth sitting with how strange the gap actually is.
Why is performance monitoring without spend monitoring a half-finished job?
Pull up your database monitoring dashboard right now. It can tell you the p99 latency of your busiest cluster to the millisecond. Now ask it what that cluster cost last week, which product feature drove the cost, and whether the number is trending up. Most dashboards have no answer to any of the three.
Organizations run world-class performance monitoring alongside spend visibility built to a decades-older standard. Engineers get telemetry in seconds. Finance gets a bill in weeks, and the people accountable for AI ROI end up making decisions with the oldest information in the building.
The gap costs more now because databases sit inside the AI value chain. They store the context, feed the retrieval, and hold the training data. When a board asks what the company is getting for its AI investment, the database layer is part of the answer.
The other part is the model bills themselves, which we track across our pricing guides for OpenAI, Claude, and Gemini. An AI feature’s true unit cost is tokens plus compute plus the database spend underneath. Miss the last piece and the ROI math is fiction.
“Public cloud usage is only getting more specialized as time goes on,” as CloudZero founder and CTO Erik Peterson put it. “Services and management tools available in the cloud are occupying a bigger and bigger slice of organizations’ cloud bills.”
That specialization is exactly why bolting a spend column onto a performance tool hasn’t worked. The cost dimension needs a platform built for it from the ground up, which is precisely the gap CloudZero exists to close.
How does CloudZero connect database performance to database spend?
CloudZero is the AI ROI company, and databases are one of the clearest places to see why the category matters. The platform manages more than $15 billion in cloud and AI spend, and database services run through nearly every dollar of it. Here’s how it works.
Native connections to the databases you already run
CloudZero ingests cost and usage data directly from Snowflake, MongoDB Atlas, Databricks, ClickHouse, and Confluent, alongside AWS, Azure, GCP, and Oracle Cloud. Your RDS instances, DynamoDB tables, and Atlas clusters land in one normalized view within hours.
AI platform costs in the same pane
Native connections ingest spend from OpenAI, Anthropic, and Cursor, with AnyCost covering anything else. The database powering your RAG pipeline and the model consuming its output finally appear on one screen: the complete AI unit cost, not a partial one.
Cost per workload, tenant, and feature, without perfect tagging
CloudZero’s dimensions map raw database spend to what the business actually discusses: products, teams, customers. That’s how one customer running more than 50 large language models in production found over $1 million in savings, by seeing which workloads earned their spend.
Anomaly detection on the spend side
The discipline you apply to latency spikes, applied to cost spikes. A misconfigured warehouse surfaces in hours, not on next month’s invoice. It’s the approach that helped Drift cut $2.4 million from COGS, and why customers average 22% savings in year one.
Performance monitoring keeps your databases healthy. CloudZero tells you whether healthy is also profitable. In this era, with databases carrying the AI stack on their backs, you need both answers, and you need them on the same screen.
Request a demo to see your database spend mapped to your products, teams, and customers, and find out what your current visibility is missing.
Frequently asked questions about database monitoring
