Home / Guides / How to Diagram a Data Pipeline (ETL & Data Flow)

How to Diagram a Data Pipeline (ETL & Data Flow)

Source, ingestion, staging, transform, warehouse — a clear way to lay out a data pipeline that doesn't turn into a wall of identical arrows.

6 min read · Free, no sign-up · Updated 2026-09-05

A data pipeline diagram has a specific job: show data moving from where it originates to where it's finally usable, through every hop in between. Done well, it's the fastest way for a new team member to understand "where does this number in the dashboard actually come from" — which is usually the question that starts an incident investigation.

The standard shape of a pipeline diagram

Most data pipelines follow a recognizable pattern, left to right:

1. Source systems — the applications or databases data originates from (an ERP, a SaaS app, an operational database).
2. Ingestion — the tool or job that pulls data out (Fivetran, Airbyte, a custom extractor, a CDC stream).
3. Raw / staging layer — where data lands before transformation, usually unmodified.
4. Transformation — dbt models, Spark jobs, stored procedures — whatever reshapes raw data into something usable.
5. Warehouse / marts — the modelled tables analysts and dashboards actually query.
6. Consumption — BI tools, reverse ETL back into a SaaS app, or downstream APIs.

Building it in FlowDiagrams

1. Open FlowDiagrams and go to ☰ → Starter templates → ETL / data pipeline for a working six-stage example to reshape, or start blank if your pipeline doesn't fit that pattern.
2. Use the Database shape (cylinder) for anything that stores data at rest — source databases, staging tables, the warehouse itself. Use plain rectangles for processing steps and tools.
3. Drop in real tool logos from the library (grid icon, top right) — Airflow, dbt, Snowflake, Databricks, Kafka and most common data-stack tools are built in under the Data and Integration categories. A pipeline diagram with actual tool logos reads faster than one with generic boxes labelled "transform."
4. Label every arrow with how the data moves and how often — "CDC, continuous," "dbt run, nightly," "manual export." This one habit is what separates a useful pipeline diagram from a vague one.
5. If you're documenting a Snowflake-based stack specifically, ☰ → Starter templates → Snowflake data platform starts from a layout already shaped around Snowflake's typical raw → staging → mart pattern.

Documenting a pipeline you didn't build

Inheriting an undocumented pipeline is the most common reason to draw this diagram. Start from the warehouse and work backward — it's usually easier to find "what feeds this table" one hop at a time than to reconstruct the whole flow from the source forward. Each hop you confirm becomes one box and one labelled arrow.

Exporting for a runbook

Pipeline diagrams are frequently linked from an on-call runbook, so export as PNG or SVG (☰ → Export image / PDF…) and embed it directly rather than linking to the live tool — during an incident, nobody wants an extra login step between them and the diagram they need.

Frequently asked questions

What's the difference between a data pipeline diagram and a data flow diagram?

A data pipeline diagram typically follows one specific technical path — source, ingestion tool, staging area, transformation, warehouse. A data flow diagram is broader, describing how data moves through a business process generally, engineering pipeline or not. The tool and shapes below work for either.

How do I show scheduled vs. real-time steps in the same diagram?

Label the connector itself — "nightly batch," "streaming," "on row insert" — directly on the arrow. That label is what a reader actually looks at first, more than colour-coding or shape choice.