Databases
PostgreSQL — planned
Will read pg_stat_user_tables for write activity, pg_proc for function bodies, pg_stat_activity for blocking. This integration is planned: documented here as reference, not connectable from the admin today.
PostgreSQL exposes more useful counters than SQL Server does, and exposes them more
honestly. pg_stat_user_tables carries per-table insert, update and delete counts
that survive as long as the statistics collector does, which makes runtime topology discovery
unusually reliable here — once a connector reads it.
The catch is that most PostgreSQL ETL is not in PostgreSQL. Where SQL Server estates keep logic in stored procedures, Postgres estates tend to keep it in an external service or a transformation tool, so the database is a strong source for targets and volumes and a weaker one for transformation logic.
PostgreSQL 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 PostgreSQL integration: what it is designed to read, and why.
What Decim will read from PostgreSQL
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 | pg_stat_user_tables | n_tup_ins, n_tup_upd, n_tup_del per table |
| Live row estimate | pg_class.reltuples | Cheap approximate counts without scanning |
| Function bodies | pg_proc.prosrc | PL/pgSQL logic where it exists |
| Dependency edges | pg_depend, pg_rewrite | View and function dependencies |
| Live contention | pg_stat_activity, pg_locks | Blocking chains during a stall |
| Column metadata | information_schema.columns | Types and nullability |
| Table sizes | pg_total_relation_size() | Growth anomalies over time |
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 ROLE decim_agent LOGIN PASSWORD '...';
-- Catalog and statistics views are readable by default.
GRANT CONNECT ON DATABASE sales TO decim_agent;
GRANT USAGE ON SCHEMA public TO decim_agent;
-- pg_stat_activity shows other sessions' queries only with this role
-- (PostgreSQL 10+). Without it, query text from other users is NULL.
GRANT pg_read_all_stats TO decim_agent;
-- Reconciliation tables, named explicitly.
GRANT SELECT ON public.intake_batch TO decim_agent;
GRANT SELECT ON public.rejected_transactions TO decim_agent;
-- Never granted: write privileges, or blanket SELECT on the schema.
ALTER DEFAULT PRIVILEGES IN SCHEMA public
REVOKE ALL ON TABLES FROM decim_agent;What it would build
What this source would contribute to the pipeline topology and to the evidence available during an investigation:
- Target nodes and their write volumes from the statistics collector
- Transform nodes where PL/pgSQL functions carry logic
- View dependency edges from pg_depend
- Contention evidence from live blocking chains
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 | n_tup_ins flat across the window |
| Duplicate load | n_tup_ins at roughly double the baseline |
| Blocking during a stall | Blocking chain in pg_stat_activity |
| Autovacuum starvation | last_autovacuum far behind n_dead_tup |
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.
- Statistics counters reset on
pg_stat_reset()and do not survive a crash-recovery restart - Transformation logic usually lives outside the database, so this source alone rarely yields transform nodes
reltuplesis an estimate refreshed by ANALYZE — never cite it as an exact count
Related integrations
- 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.
- dbt — manifest.json is the model graph; run_results.json is what actually happened. Both are artefacts, not APIs.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a PostgreSQL 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.