Application performance monitoring catches a lot of things. It catches high error rates, high latency, memory spikes, CPU saturation. What it doesn't catch is data anomalies that don't surface as application errors — data that's inserted at an abnormal rate, values that are in range but statistically wrong, referential patterns that indicate a bad sync or a runaway batch job.
The class of anomalies APM misses
Consider a scenario where a data sync job that normally inserts 10,000 rows per hour begins inserting 3 million rows per hour due to a loop bug. The application handles every insert successfully. The API returns 200s. Your APM shows nothing. But your database is filling up, your indexes are becoming bloated, and your queries that assumed stable table sizes are getting progressively slower. By the time you notice, you've ingested 30 million bad rows.
Or consider a more subtle case: a column that should only contain positive values starts receiving occasional negative numbers due to an integer overflow in a computation. The inserts succeed. The application doesn't throw errors. The values are structurally valid. But your revenue reports are wrong, and you won't find out until month-end reconciliation.
What database-layer anomaly detection looks like
Effective data-layer anomaly detection requires baselines: normal insert rates, normal value distributions, normal cardinality patterns, normal query patterns. Deviations from baseline are the signal. A 5-standard-deviation spike in row insertion rate for a table that normally grows slowly is an anomaly. A column whose distribution shifts from unimodal to bimodal overnight is an anomaly. A query pattern that appears suddenly at 100x its normal frequency is an anomaly.
Building this detection requires instrumentation at the query and write level, not the HTTP level. That's why it belongs at the database layer, not the application layer. Dreambase implements this as a continuous baseline-learning system that alerts on statistically significant deviations in write patterns, value distributions, and query frequencies — catching the class of problems that application monitoring fundamentally cannot reach.