Databases
MySQL — planned
Will read performance_schema for per-table write counts and information_schema for routines and structure. This integration is planned: documented here as reference, not connectable from the admin today.
MySQL's useful metadata is split across two schemas with different characters.
information_schema describes structure and is always available;
performance_schema describes activity and is where per-table write counts live —
but its instrumentation is partly off by default and varies by version and distribution.
Where it is enabled, table_io_waits_summary_by_table is the single most useful
view: it gives read and write counts per table since the last server start, which is enough
to establish which tables a pipeline actually touches without reading a single row.
MySQL today
Decim does not connect to databases today. Stored procedures and SQL kept in a connected GitHub repository are read during pipeline discovery and cited during an investigation. When the deciding evidence lives in the database — a row count by day, a column's values — Decim writes a check: a read-only SQL query, validated against a read-only allowlist and never executed by Decim, for someone on your team to run. The result goes back into the incident and triggers a new revision of the hypotheses.
The sources that ship today are GitHub, Google Cloud Logging, Jira Cloud and the optional Windows agent. Everything below this point describes the planned MySQL integration: what it is designed to read, and why.
What Decim will read from MySQL
The intended read-only surface for this integration. It is reference material for the roadmap — and useful on its own, because these are the views and APIs worth knowing during an incident whether or not any tool reads them for you.
| What | From | Why it matters |
|---|---|---|
| Write activity | performance_schema.table_io_waits_summary_by_table | COUNT_INSERT, COUNT_UPDATE, COUNT_DELETE per table |
| Routine bodies | information_schema.ROUTINES | ROUTINE_DEFINITION for procedures and functions |
| Table structure | information_schema.TABLES, COLUMNS | Row estimates, types, and UPDATE_TIME |
| Foreign keys | information_schema.KEY_COLUMN_USAGE | Structural edges |
| Live contention | performance_schema.processlist | Running statements and their state |
| Statement history | events_statements_summary_by_digest | Which statement shapes dominate, and their latency |
| Scheduled events | information_schema.EVENTS | MySQL's own scheduler — frequently overlooked |
Permissions it is designed around
Written out in full, because "read-only access" is not a specification. These are the grants the planned integration is designed around and may change before it ships. Nothing below grants the ability to write, and row access would be requested only on the specific tables you name. You do not need to create any of this today.
CREATE USER 'decim_agent'@'10.%' IDENTIFIED BY '...';
-- Metadata and instrumentation.
GRANT SELECT ON performance_schema.* TO 'decim_agent'@'10.%';
GRANT PROCESS ON *.* TO 'decim_agent'@'10.%';
GRANT SELECT ON information_schema.* TO 'decim_agent'@'10.%';
-- Reconciliation tables only.
GRANT SELECT ON sales.intake_batch TO 'decim_agent'@'10.%';
GRANT SELECT ON sales.rejected_transactions TO 'decim_agent'@'10.%';
-- PROCESS is needed to see other sessions in the processlist. It is a
-- server-wide grant and reveals running statement text — review it
-- deliberately rather than granting it by habit.What it would build
What this source would contribute to the pipeline topology and to the evidence available during an investigation:
- Target nodes and write volumes where performance_schema is instrumented
- Transform nodes from stored routine bodies
- Scheduled work from information_schema.EVENTS
- Structural edges from foreign key metadata
Today, topology is built from code in GitHub, and each connection is marked direct or inferred. The design direction for sources like this one is a provenance model: a step found in a definition is declared, a step seen running is observed, one that is both is verified, and where two sources disagree the disagreement is kept as a drift note rather than resolved silently. That model is planned, not shipped.
Failure modes it would surface
What this source is uniquely good at proving — and, just as usefully, at disproving. An investigation that can refute a hypothesis cheaply is worth as much as one that confirms it. Until the integration ships, the same signals can be checked by hand, or requested by Decim as a check your team runs.
| Failure mode | The signal |
|---|---|
| Load wrote nothing | COUNT_INSERT flat across the window |
| Undocumented target | Write counts on a table in no definition |
| Long-running blocking statement | processlist state during the stall |
| Silent scheduled job | An enabled row in EVENTS nobody knew about |
Limits
What this source cannot tell you, even once it is read. Stated because an investigation that overstates its sources produces confident wrong answers, which is worse than an honest cause unclear.
performance_schemainstrumentation is partly disabled by default and the setup tables must be enabled to get table-level counters- Counters reset on server restart, like every other in-memory statistic
- Aurora and other managed forks expose a subset of performance_schema — verify before relying on a view
Related integrations
- PostgreSQL — Will read pg_stat_user_tables for write activity, pg_proc for function bodies, pg_stat_activity for blocking.
- SQL Server — Will read catalog metadata, procedure bodies and write activity — the definitions git never sees.
- Apache Airflow — The metadata database holds connections, variables, pools and manual state — none of it in git.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a MySQL pipeline?
Bring an incident you already know the answer to. If Decim gets it wrong, that is a more useful demo than one where it doesn't.