Overview
In this episode of The Dashboard Effect, Brick Thompson and Caleb Oaks break down two foundational data strategies that shape how organizations store, access, and report on their data: Schema on Write and Schema on Read. The conversation moves from definition to practical application, helping teams understand not just what each approach means but when each one makes sense and why the industry has been moving decisively in one direction.
For any organization evaluating its data architecture or trying to understand why modern data lakehouses work the way they do, this episode provides a clear and useful foundation. See how Blue Margin’s Managed Data Platform applies the schema on read approach to build flexible, agile data environments that adapt to changing business requirements without requiring expensive ETL rebuilds every time the logic needs to change.
What This Episode Covers
Schema on Write (0:33 – 1:12)
The traditional data warehouse approach structures data at the point of storage. Predefined relationships and constraints are applied before the data is written, which means it is ready for reporting immediately. The trade-off is rigidity: changing the structure later requires revisiting the ingestion and transformation logic, which can be time-consuming and expensive as business requirements evolve.
Schema on Read (1:12 – 2:19)
The more modern approach, commonly used in data lakes and lakehouses, stores raw data without upfront transformation. The schema is applied dynamically through a semantic layer or query only when the data is accessed. This preserves flexibility and allows logic to be adjusted without rewriting the underlying storage or ETL processes.
When Schema on Write Still Makes Sense (2:19 – 3:07)
For very large datasets operating at tens of billions of rows, applying complex transformations at read time can generate excessive compute costs and slow performance to an unacceptable level. In those scenarios, the structured approach of Schema on Write remains the more practical choice. Scale is the primary variable that tips the decision.
The Benefits of Schema on Read for Mid-Sized Companies (4:00 – 6:01)
For the majority of mid-market organizations, Schema on Read implemented through serverless SQL provides a meaningful combination of flexibility and efficiency. Logic and column definitions can be adjusted without requiring extensive ETL rewrites, which makes it significantly easier to respond to changing reporting requirements without treating every update as a infrastructure project.
The Modern Shift Toward Data Lakehouses (6:01 – 6:57)
The industry has moved steadily away from traditional data warehouses toward data lakehouses that leverage the flexibility of Schema on Read. The hosts note that this transition has been faster and more efficient in practice than many teams anticipated, and for their clients it has translated directly into more adaptable reporting environments that can keep pace with evolving business needs.
Who It’s For
This episode is worth your time if you are a data architect or engineer evaluating storage and modeling strategies for a new or evolving analytics environment, a technology leader trying to understand the architectural trade-offs behind the lakehouse platforms your team is considering, a BI developer who wants a clearer mental model of why modern data environments work differently from the traditional warehouses they may have learned on, or any organization weighing the long-term flexibility of its current data architecture against the performance demands of its reporting workloads.
Why It’s Worth a Listen
Schema on Write and Schema on Read are concepts that come up constantly in data architecture conversations but rarely get explained in terms of practical business impact. This episode closes that gap. Brick and Landon connect each approach to the specific scenarios where it performs well and the conditions under which it breaks down, which is more useful than a purely technical definition.
The framing around mid-market companies is particularly relevant. Most architecture guidance defaults to enterprise-scale assumptions that do not translate cleanly to organizations operating at a different order of magnitude. The hosts are explicit about where the scale thresholds lie and what that means for the decision, which gives mid-sized teams a more accurate map for their own situation.
And for teams that are in the middle of evaluating or migrating to a lakehouse architecture, the perspective on how quickly that transition can deliver real efficiency gains is a useful data point for setting realistic expectations about what the work produces and how soon.
