---
title: "How Database Observability works | Grafana Labs"
description: "Architecture and data flow for Database Observability"
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

## Architecture

## How data flows

Database Observability uses Grafana Alloy to collect two types of telemetry from your databases:

| Signal      | What it captures                                             | Where it’s stored                |
|-------------|--------------------------------------------------------------|----------------------------------|
| **Metrics** | Query counts, latency, errors, rows affected, resource usage | Grafana Cloud Mimir (Prometheus) |
| **Logs**    | Query samples, explain plans, schema details, wait events    | Grafana Cloud Loki               |

## Collection sources

The data comes from built-in database statistics, not from intercepting queries:

- **PostgreSQL** uses `pg_stat_statements` for aggregate query statistics and `pg_stat_activity` for active session information. The `pg_stat_statements` extension must be installed and enabled.
- **MySQL** uses `Performance Schema`, which is enabled by default in MySQL 8.0+. Query samples are captured from running queries in the performance schema tables.

## What Grafana Alloy does

Grafana Alloy runs alongside your database and handles collection:

1. **Database exporters** scrape aggregate metrics from `pg_stat_statements` or `Performance Schema` and forward them to Grafana Cloud Mimir.
2. **Database Observability components** query your database for detailed information (query samples, explain plans, schema details) and forward structured logs to Grafana Cloud Loki.
3. **Purpose-built dashboards** in Grafana Cloud correlate these metrics and logs into a unified view of query performance.

> Explain plans run `EXPLAIN` (not `EXPLAIN ANALYZE`) on sampled queries, so they estimate costs using cached statistics without actually executing the query.