Databases
SQL Server — planned
Will read catalog metadata, procedure bodies and write activity — the definitions git never sees. This integration is planned: documented here as reference, not connectable from the admin today.
SQL Server is one of the richest single sources an investigation can have, because it holds definitions that exist nowhere else. A stored procedure altered in production has no commit; a SQL Agent job step is a row in a table; a table that quietly started taking writes last March appears in no diagram. All three are readable from catalog views.
The planned connector reads metadata rather than data. The permissions it is designed
around are VIEW DEFINITION and VIEW DATABASE STATE — no access to
rows in your fact tables at all. Row access would be requested separately and only for the
specific reconciliation tables you name.
SQL Server 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 SQL Server integration: what it is designed to read, and why.
What Decim will read from SQL Server
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 |
|---|---|---|
| Object definitions | sys.sql_modules | Stored procedure and view bodies — often the only copy |
| Object change times | sys.objects.modify_date | Tests schema-change hypotheses in one query |
| Column metadata | sys.columns, sys.types | Type and nullability, for truncation and overflow causes |
| Dependency edges | sys.dm_sql_referenced_entities | is_updated separates a write from a read — this is how edge direction is derived |
| Write activity | sys.dm_db_index_usage_stats | Which tables are genuinely being written to, and when last |
| Live contention | sys.dm_exec_requests | Blocking and waits during a stall, if run while it is happening |
| Foreign keys | sys.foreign_keys | Structural edges between targets |
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 LOGIN decim_agent WITH PASSWORD = '...';
CREATE USER decim_agent FOR LOGIN decim_agent;
-- Metadata only. No rows from user tables.
GRANT VIEW DEFINITION TO decim_agent;
GRANT VIEW DATABASE STATE TO decim_agent;
-- Reconciliation tables, named explicitly — never wildcarded.
GRANT SELECT ON dbo.IntakeBatch TO decim_agent;
GRANT SELECT ON dbo.RejectedTransactions TO decim_agent;
-- Fact tables at COLUMN scope: enough to count rows per batch,
-- structurally unable to read an amount or a customer identifier.
GRANT SELECT ON dbo.[Transaction](BatchId, LoadedAtUtc) TO decim_agent;
DENY ALTER, DELETE, INSERT, UPDATE, EXECUTE TO decim_agent;What it would build
What this source would contribute to the pipeline topology and to the evidence available during an investigation:
- Transform nodes from stored procedure bodies, with read/write edge direction
- Target and store nodes from write activity, including undocumented ones
- Structural edges from foreign keys
- Schema change history sufficient to refute or confirm truncation causes
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 |
|---|---|
| Silent schema change | modify_date inside the incident window |
| Undocumented reject table | Write activity on an object in no definition |
| Contention with another workload | Blocking sessions and waits during the stall |
| Truncation on insert | Column max_length against the values being written |
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.
- Live contention queries only show requests executing at that moment — they must run during the stall, not after
- Query Store gives far better historical plan and duration data, but is off by default on older instances
- Cross-server topology needs a login on each instance; linked-server hops are not followed automatically
Related integrations
- SQL Server Agent — Job steps are rows in msdb, not files in git. Will read sysjobs, sysjobsteps and sysjobhistory.
- SSIS — SSISDB holds executions, per-component row counts and the parameter values actually used.
- PostgreSQL — Will read pg_stat_user_tables for write activity, pg_proc for function bodies, pg_stat_activity for blocking.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a SQL Server 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.