Three kinds of thing are drawn. Cards are scheduled jobs, web apps or manual work; the stripe colour is where they run. Rows inside the two boxes are groups of database tables, in the prod or dev database. Ledger rows on the right are CERF frameworks with their last recorded pre-arranged envelope; a greyed row's latest version is not currently active (in development, superseded, retired or expired, using the catalog's lifecycle rule), though its monitor may still run. Data flows left to right: jobs on the left write the tables, consumers on the right read them, dotted lines link a monitor to the framework it triggers. When an item is selected its connections are highlighted in blue: solid for writes, dashed for reads. A consumer that also writes carries an "also writes" tag and a line back into the database. ▲ marks a job the pipeline registry showed failing or overdue at its last snapshot. Click the item again, an empty area, or the clear button to deselect.
Email lists are shown by Listmonk id and tag only. Subscriber counts are not copied into the knowledge base (a snapshot goes stale and misleads, D120): open Listmonk, or ask it through the API, for who is on a list right now — see comms-listmonk.md.
Generated by scripts/gen_db_network.py from page frontmatter, the DB table snapshots and the pipeline registry (snapshot 2026-10-08 17:02 UTC); curated text lives in infrastructure/db-network.yml.
scripts/gen_db_network.py
infrastructure/db-network.yml
This map shows who reads and writes each database. The servers' network configuration and the September 2026 incident are documented in the internal KB (ds-knowledge-base-internal: infrastructure/db-network-access.md, incidents/). Pages that still declare dev-stage reads are listed under Unreviewed below until they are re-synced.
Each framework row shows the last pre-arranged CERF envelope recorded on a non-retired version of that framework; the row's detail says which version it comes from and whether the latest version records an envelope at all. Several 2026 versions do not yet, so the figures are an order of magnitude, not an audited total.
Frameworks whose live monitoring never opens a database connection: Kenya drought, Somalia floods, Fiji storms, Mozambique cholera, Myanmar cyclones, Bangladesh cyclone. Also the Nigeria gauge pilot, AFRO cholera, ROSEA thresholds, ACLED and GFM flood pipelines.
Evidence for a clean-up, never an automatic action: jobs long dead in the registry, things with zero connections on this map, pages already stopped or superseded, and at the end every pipeline or app the map does not show at all — with its status, runtime, dependents and registry health, so the ones nobody depends on stand out.
What to move first, ranked by how much depends on it: CERF frameworks and their envelopes, framework monitors, other consumers and email recipients downstream. Two lists, because the two moves are independent: off GitHub-hosted runners onto Databricks, and off the dev database onto prod.
Nothing downstream on the map, so no priority from this view: Analysis notebooks, afro-cholera, fms-tc-outlook, hdx-floodscan, rosea-thresholds-monitoring, storm-exposure-compare, storm-impact-harmonisation, teleconnections.
Nothing downstream on the map, so no priority from this view: KB MCP servers · chatbot · KB workflows, seas5-viz · seas5-skill, storm-exposure-compare, storm-impact-harmonisation, teleconnections.
Score = 4 per active CERF framework downstream + 1 per inactive one + 2 per framework monitor + 0.5 per other consumer + the active frameworks' pre-arranged envelope in $M, +1 if the item is itself a monitor. Downstream is the same chain a click on the map highlights. A high score means many systems, frameworks and dollars stop when this item loses its database path.