All Articles
Search and filter all parables by series or tag.
Part 19: Designing the Hospital's Quality Program
After walking every ward, the practical question a hospital administrator actually faces is simple to ask and genuinely hard to answer well: what does a real, working quality program look like, end to end?
Part 20: The Whole Hospital, Healthy
How every concept from this series fits together as one connected hospital, and where data quality and observability are actually headed as AI reshapes what watching over data even means.
Part 17: When the Patient Is an AI Agent
A patient who can describe their own symptoms helps a doctor enormously. An AI agent consuming bad data can't tell you anything's wrong — it just acts on it, confidently and immediately.
Part 18: Not Every Patient Needs the ICU
The ICU delivers the most intensive monitoring a hospital has. It's also enormously expensive to run, and putting every patient there regardless of actual need would bankrupt the hospital without helping anyone.
Part 15: Bedside Manner for the Data Team
How a doctor tells a patient what's wrong matters almost as much as the diagnosis itself. How a data team communicates a quality incident deserves exactly the same care.
Part 16: Preventive Care Beats the ER
Catching a problem in a routine checkup is cheaper, calmer, and far less risky than catching the same problem in an emergency room. The exact same logic applies to catching bad data at its source.
Part 13: When the Patient Can't Tell You What's Wrong
The most dangerous cases aren't the ones screaming in pain — they're the ones that look and feel completely fine while something serious develops quietly underneath.
Part 14: The Diagnosis That Writes Itself
A specialist reviewing a chart doesn't just spot that something's wrong — a great one drafts a likely diagnosis on the spot, from the pattern alone, before a single additional test is run.
Part 11: Always Get a Second Opinion
One test result, taken alone, can mislead even a good doctor. A second, independent check — a different test, a different angle — is what actually builds confidence in a diagnosis.
Part 12: Pre-Existing Conditions
Not every unusual reading on a chart is a new emergency — some are documented, understood, long-standing conditions. Treating every one as a fresh crisis wastes attention that a real emergency needs.
Part 10: Quarantine Before It Reaches the Ward
A hospital doesn't wait to see if a contagious case spreads before isolating it — containment happens the moment something's identified as risky, before it ever reaches the rest of the ward.
Part 9: A Fever Is Useful Information
A fever feels like a problem. It's actually the body doing something useful — signaling that it's fighting something, and telling you where to look. The best data anomalies work exactly the same way.
Part 7: The Chart at the Foot of the Bed
Every treatment, every medication, every test result goes on the chart — not for paperwork's sake, but because the next person treating this patient needs to know exactly what's already happened.
Part 8: Reading Vitals Without Waking the Patient
A monitor that has to physically disturb a sleeping patient every time it takes a reading isn't actually a good monitor — the best ones check constantly without the patient ever noticing.
Part 5: Taking a Baseline Before Anyone Gets Sick
You can't tell a fever from a normal reading if you never established what normal actually looks like for this specific patient. Data quality has the exact same prerequisite, and it's easy to skip.
Part 6: Triage: Who Gets Seen First
An emergency room doesn't treat patients in the order they walked in — it triages by severity, because treating every case as equally urgent means the truly urgent ones wait too long.
Part 3: The Symptom Isn't the Diagnosis
A fever tells you something is wrong. It doesn't tell you what. Treating the symptom instead of finding the actual cause is how the same problem keeps coming back, in a hospital or a data pipeline.
Part 4: Six Vital Signs, One Patient
A doctor doesn't just check one thing and call it a full assessment — a real checkup covers a specific, established set of vital signs. Data quality has its own equivalent set, and it's worth knowing by name.
Part 1: The Vitals Nobody Was Checking
A hospital that only checks a patient's vitals once, at admission, misses everything that happens after — and a lot of organizations run their data the exact same way.
Part 2: A Checkup Once a Year Isn't a Checkup
An annual physical catches a lot. It also completely misses whatever happened in month seven — and that blind spot is exactly what periodic data quality checks share with once-a-year checkups.
Part 19: Retiring the Old Power Plant for Good
the final, deliberate step of a cloud data warehouse migration: fully decommissioning legacy infrastructure once the transition is genuinely verified.
Part 20: A City Fully Wired
reassembling every piece covered across this series into the complete picture of what a genuinely well-run cloud data warehouse looks like.
Part 17: Building Codes for the New Wiring
why governance and compliance responsibilities don't disappear just because a data warehouse's infrastructure is now fully managed.
Part 18: The Smart Meter That Talks Back
how observability into query performance and resource usage lets an organization actually understand and optimize its cloud data warehouse.
Part 15: The Grid That Reaches Every Building in the City
how cloud data warehouses support global and multi-region data distribution, and why this matters for latency, compliance, and resilience.
Part 16: When the Power Company Changes the Rate Plan
the genuine risk of vendor lock-in and pricing model changes, and how to plan for them deliberately rather than being caught off guard.
Part 13: Reading the Bill Line by Line
why attributing cloud data warehouse cost to specific teams, workloads, and queries is essential to genuinely managing it well.
Part 14: Bringing Your Own Appliances
how secure data sharing works between organizations on a cloud data warehouse, without requiring risky, duplicated data copies.
Part 11: Sharing the Grid With Your Neighbors
how a cloud data warehouse handles multiple teams and workloads sharing the same underlying platform without interfering with each other.
Part 12: The Circuit Breaker That Protects the House
how resource governance and concurrency controls protect a cloud data warehouse from being overwhelmed by a single runaway query or workload.
Part 10: A Backup Generator for When the Grid Goes Down
how redundancy and disaster recovery planning work for a cloud data warehouse, even though the underlying infrastructure is fully managed.
Part 9: The Meter Running Even When the Lights Are Off
the real, common risk of idle or forgotten compute resources quietly running up costs, and the discipline needed to catch this waste.
Part 7: Wiring the House for the Grid
the practical migration path organizations follow when moving from an on-premises data warehouse to a cloud-native one.
Part 8: Choosing Your Utility Provider
the genuine, practical factors that go into selecting a cloud data warehouse platform, beyond just feature comparison lists.
Part 5: Turning the Dial Up During Peak Demand
how elastic compute scaling lets a cloud data warehouse handle genuinely variable demand without either under- or over-provisioning.
Part 6: The Substation That Never Sleeps
what a fully managed service model actually means for a cloud data warehouse, and what operational responsibility genuinely shifts to the provider.
Part 3: Before the Grid Existed
how organizations provisioned and managed data warehouse capacity before cloud data warehouses existed as a mature, practical option.
Part 4: Storage and Power Metered Separately
why decoupling storage from compute is the single most important architectural shift cloud data warehouses introduced.
Part 1: Plugging Into the Grid
why cloud data warehouses let organizations plug into shared, elastic infrastructure instead of building and running their own, the way a utility grid replaces a private power plant.
Part 2: What the Meter Actually Measures
how cloud data warehouse billing actually works, and why understanding what's metered separately is essential to using the model well.
Part 10: A Reference Architecture for AI-Native Analytics (2026 Edition)
The capstone: every district from this series, laid out on one blueprint — plus a checklist to see how AI-ready your own architecture really is.
Part 9: Designing the Analytics Org Around AI: Architecture Is Also a People Problem
AI didn't just join the team — it changed the lineup. Here's how analytics roles are shifting from "build it" to "judge it."
Part 7: The Composable Data Stack Meets the Agentic Layer
Best-of-breed tools gave teams great instruments. AI orchestration is the conductor that finally lets them play together, on demand.
Part 8: Cost, Compute, and Context: The New Trade-offs in AI-Era Architecture
AI in your pipeline isn't free reasoning — it's a utility bill. Here's how to budget for inference cost and context windows before they budget for you.
Part 5: Self-Serve Analytics, Reimagined: When the BI Tool Talks Back
Dashboards answer the questions they were built for. Conversational BI answers the question you actually ask — if it's grounded in the right data underneath.
Part 6: Architecting for Real-Time: Streaming Meets Intelligent Agents
Monthly reports describe what happened. Real-time, AI-driven pipelines decide what happens next — and that speed comes with real new risks to design around.
Part 3: From ETL to ETA: Extract, Transform, Augment
ETL just got a new job description. AI is showing up mid-pipeline — tagging, classifying, and enriching data before it ever reaches a dashboard.
Part 4: The Architecture of Trust: Governance Patterns for AI-Augmented Analytics
One review checkpoint near the end used to be enough. Now that AI can act anywhere in the pipeline, governance has to watch the whole sky, not just one gate.
Part 1: The Analytics Stack Is Dead. Long Live the Analytics Fabric.
The traditional data stack was built like a one-road town — one direction, one destination. AI is turning it into a connected city, and architecture has to catch up.
Part 2: Designing for the Machine Reader: Why Your Data Model Needs a New Audience
Your data model was built for human analysts who could fill gaps with memory and guesswork. AI can't do that — and that changes what "good documentation" really means.
Part 19: The Contractor Who Reads Every Blueprint at Once: AI-Assisted Schema Change Impact Analysis
why a contractor who could instantly cross-reference every building's blueprint in the city would catch problems no single-building review ever could, and what AI-assisted schema change impact analysis does at that same scale.
Part 20: The City That Never Stops Being Built
from the first rolled-up blueprint to the contractor who reads every blueprint in the city at once, every article's lesson reassembled into one city that keeps being built on, safely, without ever needing to be torn down.
Part 17: The Condemned Wing: Deprecating and Removing Old Schema Elements
why a building manager posts a condemnation notice with a real timeline before finally demolishing an empty wing, and why deprecating old schema elements deserves the same deliberate, visible process.
Part 18: A City of Many Boroughs, Many Blueprints: Schema Evolution in Distributed Systems
why a city made of independently governed boroughs can't renovate on one unified timeline, and why schema evolution across microservices requires the same decentralized discipline.
Part 15: The Permit Office: Schema Change Review and Governance
why a city requires a permit before real construction begins, and why schema changes benefit from the same deliberate review checkpoint.
Part 16: Moving Tenants to the New Wing: The Expand-Contract Migration Pattern
why a building manager moves tenants into a new wing before demolishing the old one, and how the expand-contract pattern applies this same sequencing to schema migrations.
Part 13: The Plaque on the Cornerstone: Schema Versioning Schemes
why a building's cornerstone plaque records exactly which year and revision it was built to, and why a schema needs the same clear, honest versioning.
Part 14: Two Crews Reading the Same Blueprint: Backward and Forward Compatibility
why a renovation crew and the building's existing tenants sometimes have to work from the same set of drawings during a phased transition, and what backward and forward compatibility mean for a schema.
Part 11: Additions Don't Need a Demolition Permit: Additive Schema Changes
why adding a new room to a house is a much smaller undertaking than tearing down a load-bearing wall, and why additive schema changes are the safest, cheapest kind of schema evolution.
Part 12: Which Walls Are Load-Bearing: Identifying Breaking Changes
why a contractor checks the structural drawings before touching any wall, and why identifying which schema changes genuinely break something is the core skill of safe schema evolution.
Part 10: The City, Reassembled
How every concept from this series fits together as one AI-ready city, and where data modelling's evolving relationship with AI is likely headed next.
Part 9: A Tour Guide for the City's Data
What semantic layers and knowledge graphs add on top of a data model, and why AI tools are only as trustworthy as the shared meaning they're given.
Part 7: Renovating a House With People Still Inside
How schema evolution and versioning let a data model change safely over time without breaking everything downstream — and how AI is making it safer to swing the hammer.
Part 8: An Apprentice Who Drafts While You Decide
What AI-assisted and automated data modelling tools actually do today, and why the human architect's judgment still matters as much as ever.
Part 5: Designing the Store Floor
How dimensional modelling (star and snowflake schemas) organizes data around how people ask questions, not just how it's stored — and how AI is changing who's "walking the store."
Part 6: The Library and the Storage Unit
The difference between modelling for a data warehouse versus a data lake — structure-first versus store-first approaches — and how AI is starting to act as an on-demand librarian for the more flexible option.
Part 3: Who's Related to Whom
How entity-relationship modelling works — entities, attributes, and relationship types — through the familiar lens of a family tree, and how AI is changing the way relationships get discovered.
Part 4: A Pantry That Makes Sense
What normalization (and denormalization) actually mean, why duplicated data quietly causes inconsistency, and how AI is changing how that duplication gets found.
Part 1: A City, Still Rolled Up
Before there's a city, there's a rolled-up blueprint and an empty lot — the same is true of any data ecosystem, and never more so than now, when AI has joined the list of residents who'll need to read the plan.
Part 2: Three Drafts of the Same House
The three levels every data model passes through — conceptual, logical, and physical — and how AI is starting to help draft each one faster.
Part 19: Which Dock Does Your Cargo Actually Need?
After walking the whole port, the practical question every shipper actually faces is simple to ask and genuinely hard to answer well: which dock does this specific cargo need, right now?
Part 20: The Whole Harbor, Working as One
How every concept from this series fits together as one connected port, and where warehouses, lakes, and lakehouses are actually headed as AI reshapes what a harbor even needs to do.
Part 17: Ships That Don't Wait to Dock
Most cargo waits for a ship to fully dock before anything gets unloaded. Some cargo can't wait that long — it needs to move the moment it's ready, straight into the yard, without ever pausing at the gate.
Part 18: Relocating the Whole Port
Moving an entire working port to a new location without ever closing it down is one of the hardest operations in shipping — and migrating a live warehouse or lake to a lakehouse is exactly that hard.
Part 15: Asking the Harbormaster Instead of Reading the Manifest
Most people visiting a port don't want to read a manifest themselves — they want to ask the harbormaster a plain question and get a straight answer. AI is turning that same shift loose on data platforms.
Part 16: A New Kind of Cargo Nobody's Manifested Before
Every cargo type this series has covered fits somewhere on a manifest. Vector embeddings don't — they're a genuinely new kind of freight, and the harbor is still figuring out how to store and find them.
Part 13: Who's Allowed on the Dock
A port with a perfect directory still needs a gate — knowing where every container is means nothing if anyone can walk up and open whichever one they want.
Part 14: Paying by the Container or by the Ton
A port can bill by container slot, by weight, by crane-hour, or some blend of all three — and each pricing model quietly rewards a different way of running your operation.
Part 11: Cranes You Can Rent by the Hour
A port that owns a fixed number of cranes either sits idle during quiet periods or grinds to a halt during a surge — renting cranes by the hour, separate from the yard itself, solves both problems at once.
Part 12: The Port's Master Directory
Even a perfectly zoned, perfectly labeled yard is useless if nobody knows it exists — the port's master directory is what actually lets anyone find anything without walking the whole yard themselves.
Part 10: A Ledger for the Open Wharf
A wharf without a reliable ledger can't promise you that the count it just gave you is still accurate a second later — table formats bring that ledger, and real transactional trust, to lake storage.
Part 9: Which Crate Are We Actually Using?
Not every container is built the same way — some are optimized for stacking density, some for quick access, some for specific cargo types. Open file formats are the same choice, one level below the yard.
Part 7: Sorting by What's Inside, Not When It Arrived
A yard organized by arrival order makes you search the whole lot for one item; a yard organized by contents lets you go straight to the right row — that's the entire case for columnar storage.
Part 8: Zoning the Yard
A container yard the size of a small city only works because it's divided into zones — and a lakehouse handling billions of rows depends on the same idea, called partitioning and clustering.
Part 5: Crates, Barrels, and Loose Cargo
A harbor handles three fundamentally different kinds of freight — neatly stacked crates, sealed barrels, and loose cargo with no fixed shape — and every data platform has to handle the same three kinds of data.
Part 6: Label It Now or Label It Later
Every port eventually has to answer the same question for every shipment: fill out the manifest before it's stacked, or leave it for whoever comes looking later? Neither answer is universally right.
Part 3: Cargo Dropped at the Wharf
The open wharf takes cargo first and asks questions later — that deferred, flexible discipline is what makes a data lake genuinely useful, and genuinely risky, in equal measure.
Part 4: One Port, Two Systems, Working Together
A modern port doesn't force every ship to choose between the depot and the wharf — it runs both as one integrated operation, and that's exactly what a lakehouse does with data.
Part 1: Two Docks, One Harbor
Every port has two very different ways of handling cargo — a precisely organized container depot and a wide-open wharf where anything can be dropped off — and that's exactly the split between a data warehouse and a data lake.
Part 2: Every Container Has Its Manifest
A container depot only works because nothing gets stacked in the yard without a manifest filled out first — that upfront discipline, applied to data, is what makes a warehouse a warehouse.
Part 19: Tasting Constantly, Not Just at the End
A good chef tastes throughout service, not just once before the doors open — pipeline monitoring is the same habit, running continuously instead of only checking whether last night's batch finished.
Part 20: The Whole Kitchen, Running Itself
How every concept from this series fits together as one connected kitchen, and where pipelines are actually headed as AI takes over more of the cooking without ever owning the menu.
Part 17: The Price of Keeping the Stove On
A burner left on with nothing cooking on it still costs money — an inefficient pipeline does the same thing with compute, and the waste is just as invisible until someone actually looks at the bill.
Part 18: Blending It Smooth Enough to Drink
A diner who can only take food through a straw needs it prepared completely differently than one sitting at a table with a knife and fork — pipelines feeding an AI system need the same fundamental rethink, not just a smaller plate.
Part 15: Choosing Your Kitchen Equipment
No kitchen buys one giant machine that does everything — it's a set of purpose-built tools working together, and the modern pipeline toolkit breaks down the same way, once you know what each category is actually for.
Part 16: Describing the Dish, Not the Recipe
Telling a skilled cook 'something bright and citrusy to cut the richness' can get you most of the way to a finished dish without ever writing the recipe yourself — natural-language pipeline generation works the same way, with the same real limits.
Part 13: Watching the Walk-In Door
Instead of counting the whole pantry every hour to see what changed, a smart kitchen just watches the door — change data capture applies the same trick to a database, catching every change the moment it happens.
Part 14: Catching Up After the Kitchen Was Closed
A kitchen that's shut for a week doesn't just reopen and pretend nothing happened — backfilling is how a pipeline properly accounts for a gap instead of leaving a hole in the record forever.
Part 11: Tasting Before Service
No serious kitchen sends out a dish nobody has tasted — pipeline testing is the same discipline, catching a broken transformation before it reaches a dashboard instead of after.
Part 12: When the Supplier Changes the Recipe
A supplier who quietly swaps an ingredient without telling anyone can ruin a dish nobody thought to double-check — schema drift does the same to a pipeline, and surviving it gracefully is different from just detecting it.
Part 10: Which Farm Did This Carrot Come From
When a customer gets sick, a good kitchen can trace one dish back to the exact delivery it came from — pipeline lineage does the same for a number on a dashboard, and it's often the difference between a quick fix and a guessing game.
Part 9: The Reject Bin
A good kitchen doesn't throw out a whole delivery because one crate of tomatoes is bruised — it sets the bad ones aside and keeps service moving, and that's exactly what a pipeline needs to do with records that fail validation.
Part 7: Restocking the Pantry, Not Rebuilding It
A kitchen doesn't empty and refill its entire pantry every time one delivery arrives — incremental loading applies the same common sense to pipelines, and getting it wrong is one of the most expensive mistakes a pipeline can make.
Part 8: The Ticket Rail
A kitchen doesn't fire every dish the moment its ticket arrives — the ticket rail enforces order and dependency, and that's exactly what a pipeline orchestrator does for jobs that can't just run whenever they feel like it.
Part 5: Prep Now or Prep to Order
Two kitchens can serve the same menu with opposite philosophies — prep everything before service, or store raw ingredients and cook to order — and that's the real difference between ETL and ELT.
Part 6: Cooking the Same Order Twice Shouldn't Double the Bill
A ticket that gets fired twice by accident should still result in one dish, one bill — idempotency is the unglamorous property that keeps a pipeline safe to rerun when something goes wrong.
Part 3: The Prep Station
Washing, chopping, and standardizing ingredients is where a kitchen actually earns its reputation — and transformation is where a data pipeline does the same, increasingly with an AI line cook working the station.
Part 4: Plating for the Right Table
A perfectly cooked dish sent to the wrong table, or served cold, or plated in a way the diner can't actually eat, is still a failure — loading is where a pipeline either delivers on all that prep work or quietly wastes it.
Part 1: From Farm Truck to Dinner Plate
Every data pipeline is really a kitchen: raw ingredients arrive messy and unlabeled, get prepped and cooked, and land on a plate someone can actually use — and AI is changing who does the prep work, not why the kitchen exists.
Part 2: Reading the Delivery Slip
What 'extract' really means when the source data doesn't cooperate — and how AI is starting to do the work of a receiving clerk who can make sense of an unfamiliar delivery on sight.