Flexibility Has a Price Tag. Most Organisations Don't Know What They're Paying.

The modern data lakehouse is built on a promise: store your raw data cheaply and without constraint in object storage, and figure out its structure later when you actually need to query it. Schema-on-read — the technical term for this approach — became the defining feature of the big data era, and it persists today as the default posture of most data lake architectures.

The appeal is genuine. In the early stages of building a data platform, you often don't know exactly what questions you'll need to answer. Schema-on-write, the traditional data warehouse approach, forces you to define your data model before you understand your use cases — a cart-before-the-horse problem that leads to months of modelling work and rigid structures that can't accommodate new questions without significant re-engineering.

But here's what nobody tells you when you're setting up your first Delta Lake or Apache Iceberg table with schema evolution enabled: at scale, late-binding schema creates a class of data quality problems that are extraordinarily difficult to detect and devastating in their downstream effects.

The Silent Data Type Problem

Consider a common scenario. Your source system exports a "customer_tier" field that contains values like "Gold", "Silver", "Bronze". Your ingestion pipeline infers the schema as STRING. Six months later, the source system team decides to represent tiers numerically: 1, 2, 3. Your ingestion pipeline, which has been running in schema inference mode, silently updates the column type to INTEGER. The existing STRING values are either coerced (potentially incorrectly) or lost, depending on how your lakehouse handles type evolution.

Your downstream ML feature pipeline, which was trained on the string values, now silently receives integers. Model behaviour changes in ways that may not manifest as obvious errors — just slow, imperceptible degradation in prediction quality. The dashboard that was reading "Gold" customers now breaks with a type mismatch. Your data team spends three weeks debugging an issue whose root cause is a schema change that nobody documented, in a pipeline that had no schema enforcement.

The Null Propagation Problem

Schema-on-read environments are particularly permissive about nulls. When a field appears in some records but not others — common in JSON sources from microservices architectures — it's represented as nullable by default. Over time, as business logic changes, fields that were reliably present become intermittently absent. Fields that should never be null start containing nulls. Without schema enforcement at ingestion, these changes propagate silently through your entire data pipeline.

The consequence for ML systems is particularly severe. Feature pipelines that assume non-null values start producing NaN or zero-imputed features. Models trained on clean data now operate on partially imputed data. The degradation is gradual and hard to attribute, because the raw data "looks fine" — it's just missing values in columns that used to be reliable.

What the Evidence Shows

In our experience building and auditing data platforms across seven industries, the organisations that operate entirely in schema-on-read mode consistently underestimate the cost of data quality incidents by a factor of 3–5x. The direct cost of a data quality incident — identifying the root cause, writing a fix, reprocessing affected data, and notifying downstream consumers — is typically measured in days of senior engineer time. The indirect cost — ML model retraining, dashboard corrections, business decisions made on incorrect data — is often an order of magnitude larger and much harder to quantify.

The Right Balance

The solution is not to abandon the data lakehouse model and return to the rigid schema-first world of the traditional data warehouse. The right answer is selective schema enforcement: apply schema-on-write discipline at the boundaries of your data platform (ingestion from source systems, promotion between data tiers), while preserving schema-on-read flexibility in the exploratory and raw zones where new data sources are being onboarded.

Practically, this means: use Great Expectations or Soda for schema validation at ingestion. Use dbt contracts or Iceberg schema evolution policies to control how schemas can change in curated layers. Implement schema registry solutions for streaming sources. And critically — build alerting around schema changes so that any modification to a production table triggers a notification to all downstream consumers.

Flexibility without guardrails is not an architecture. It's a liability waiting to materialise.