Published portfolio view — clean read
← All work
Helix (enterprise data platform) ·Platform Architect ·2022 — 2026

How 7 engineers ran 150B records/day across ~10,000 DAGs

A four-year case study of building and operating an enterprise data platform from inside a business org — no IT support, no test-infra budget — and making an AI agent a first-class operator.

4 yrs
Build period
4–7
Engineers
14 / 44
Orgs / Pods
300
Peak users
~10k
DAGs (PROD+UAT)
~9.5k
Tables
~700
Source systems
150B
Records / day
~5 PB
Peak month
14×
Data growth Y/Y
128
Peak deploys / day
<60s
Click → prod SLA
81
MCP tools (AI ops)
01

The Leverage Story

Confirmed

A team of 4–7 engineers, embedded in the business org with no dedicated IT support, built and operated over 4 years a platform serving 14 orgs and 300 peak users. It runs ~10,000 DAGs producing ~9,500 tables from ~700 source systems, processes ~150 billion records/day and ~5 PB in a peak month, and absorbed a multi-million-dollar Oracle-to-BigQuery migration spanning 2,500 DAGs.

Leverage ratios

RatioValue (at 7 engineers)Why it matters
DAGs / engineer~1,440Industry typical: 30–100. Pipelines are not engineer-touched.
Users / engineer43:1Tier-1 support is automated into the product, not into team capacity.
Records / engineer / day~21BOperational efficiency, not raw scale, is the story.
Deploys / engineer at peak~18 / dayEngineers don’t approve deploys. Governance is delegated to org QA roles.
02

The Constraint Set

Confirmed
ConstraintImplication
Business-org placementNo dedicated IT support. Infrastructure access was negotiated, not requisitioned.
Zero test-infra budgetNo automated test suite. Compensating control: a full-volume UAT replica.
No network-layer controlIPv6-only databases on segregated networks → custom SSH tunneling for data access.
Cloud topology imposedMetadata on managed Postgres, warehouse on BigQuery, legacy on Oracle — availability, not choice.
Team owns dev + support + releasesSelf-service must be the default; capacity for individual requests is near-zero.
03

The User Contract

Confirmed

Analysts write SQL. They click a button. A governed pipeline — DAG, target schema, deployment, audit trail — is live in production in under a minute.

What users never write

  • YAML — internal intermediate representation only
  • DDL — inferred from SQL, generated, queued, approved, applied
  • Python / DAG code — generated from templates at deploy time
  • Deployment scripts — replaced by the in-platform CI/CD subsystem

What users do write

  • SQL — source SELECT statements and transformation logic
  • UI-declared metadata — DAG type, schedule, target, keys, validation thresholds
04

Layer 1 · SQL or Config, Never Code

Corrected
L1
Users describe intent; the platform compiles it
Transformation DAGs: user writes SQL. Movement DAGs (HIST / File / SFTP / Sheets): user fills config fields. No user-written Python, ever. All 28 DAG types reduce to one of these two surfaces.

The discipline this forces: parse-time hygiene

At ~4,500 DAGs per environment, the scheduler re-parses the entire estate every few seconds. If any DAG file does real work at module-load, the scheduler falls behind and the platform degrades. The self-imposed rule: almost nothing runs at parse time.

  • Connections, file handles, and clients are constructed inside execute(), never at __init__
  • Library imports must be lazy or cheap
  • The DAG processor is tuned to keep parse cycles bounded
05

Layer 2 · Auto-DDL + Sub-Minute Deploy

Confirmed
L2
Click → in prod, <60 seconds, with DDL coordinated
Schema inferred from SQL via cursor introspection. DDL generated by a factory pattern, queued in an async service, applied with a first-class user-recoverable failure state. DAGs distributed via git + 60s polling. The sub-60s SLA is the polling interval — structural, not stretched.
packagevalidateDDL queuecommitgit pushnode polllive
30

Outcomes & Numbers

In progress
MetricFigure
Users / engineer43:1
Idea → production<60s
Peak deploys / day128
Data growth Y/Y14×
AI operator tools81
At-scale processing~$7 / TB
31

The Thesis

Draft

Leverage at this ratio isn’t a tooling trick — it’s the compounding of four correct abstractions over four years. Build the boring layer right, and the impressive layer comes almost for free.

Take people out of the loop one loop at a time — the engineering loop, then the deployment loop, then the clicking loop. Each abstraction is only possible because the one beneath it held. The AI operator isn’t the story; it’s the dividend of work that was correct before the category existed.