Ask five people on a media data team where the numbers should live and you will get five confident answers. The audience editor wants pageview logs stretching back years. The subscriptions lead wants clean, queryable revenue tables. The video team just wants to know whether anyone finishes a two-minute explainer. Every one of those needs is reasonable, and each one pulls you toward a different kind of storage.
Data lakes and data warehouses sit at opposite ends of that pull. Neither is the "right" answer on its own. What matters is knowing which questions each one answers well, and being honest about the maintenance each demands.
What each one actually is
The data warehouse
A warehouse stores data that has already been cleaned, shaped and given a defined structure before it is loaded. Columns have types, tables have relationships, and everything speaks SQL. When someone asks "how many digital subscriptions did we start in March, broken out by section," the warehouse has that number ready because someone decided in advance how a subscription and a section should be recorded.
That upfront work is the whole point. It makes queries fast and results consistent across teams. It also means changing your mind is expensive: adding a new event type or redefining what counts as an "active" subscriber usually means a migration.
The data lake
A lake stores files more or less as they arrive — raw JSON event streams, server logs, CSV exports from ad platforms, video player telemetry, transcripts. Nothing is modeled on the way in. Structure is applied when you read the data, not when you write it.
That flexibility is useful when you do not yet know what you will ask. It is also how lakes turn into junk drawers: thousands of files with names like export_final_v3.csv and nobody left who remembers what is inside them.
The one difference that decides most arguments
Warehouses use schema-on-write. Lakes use schema-on-read. Everything else — cost, speed, who can use it, how much engineering it needs — follows from that single choice.
Schema-on-write buys you trust and speed at query time. Schema-on-read buys you optionality and cheap storage. A newsroom running a daily traffic dashboard is buying trust and speed. A newsroom trying to figure out which reader behaviors precede a cancellation is buying optionality, because the useful signal is buried in events nobody thought to model.
Side by side
- Data types: warehouses want structured rows and columns; lakes accept anything, including images, audio and half-broken log files.
- Loading: warehouses require a transformation step before data lands; lakes accept a raw dump in minutes.
- Query speed: warehouses are typically much faster for repeated, well-defined questions; lakes are slower unless you invest in file formats and partitioning.
- Cost profile: lakes are cheap to store and expensive to query at volume; warehouses are the reverse — pricier storage, cheaper and more predictable queries.
- Who can use it: warehouses suit editors and analysts who know SQL; lakes often need a data engineer or a Python notebook in the loop.
- Failure mode: a neglected warehouse becomes rigid and outdated; a neglected lake becomes an unsearchable swamp.
The newer "lakehouse" pattern tries to blur the line by putting a table format on top of object storage. It works, but it does not remove the need to decide what your data means — it just moves that decision later.
Where newsroom analytics actually lives
Most media organizations end up with both, and the split is usually sensible. Here is how it tends to look in practice.
- Warehouse: subscriber counts, churn by cohort, article performance joined to CMS metadata, newsletter signups, campaign revenue, recurring dashboards the newsroom checks each morning.
- Lake: raw pageview and scroll events, ad server logs, social platform exports, podcast and video telemetry, anything you want to keep for years but do not yet know how to model.
The useful mental model: the lake is where data lands, and the warehouse is where it becomes an answer. A typical pipeline loads raw events into the lake, runs a nightly job to clean and aggregate them, and writes the result into warehouse tables that a dashboard reads. Editors never touch the lake, which is fine — they should not have to.
Costs, skills and the swamp problem
Storage is the least interesting part of the bill. Query compute, orchestration and, above all, human time usually dominate. A lake with no catalog, no naming convention and no retention policy costs almost nothing to store and a great deal to use.
Three habits keep either system healthy:
- Name and document every table or bucket the day it is created, with an owner attached.
- Set a retention rule before you load anything, not after a legal request arrives.
- Keep a single definition of contested terms — "active subscriber," "engaged reader," "unique visitor" — in one place both systems reference.
That last point matters more than the technology. Two teams quoting different subscriber numbers damages trust in the whole data function, regardless of where the rows sit. And since reader data touches privacy and retention rules that vary by jurisdiction, run any decision about what you keep and for how long past your legal team rather than guessing.
A practical way to choose
- Write down the ten questions your newsroom asks most often. Be specific about frequency and audience.
- Sort them into recurring dashboards and one-off exploration. Recurring questions belong in a warehouse.
- Inventory your raw sources: volume, format, update frequency, and how much cleaning each needs.
- Ask who will query the result. If editors need self-serve access, lean warehouse. If only a data engineer will ever open it, a lake is fine.
- Start with one warehouse table and one lake bucket. Resist building the full architecture before it earns its place.
- Revisit after a quarter. Whatever nobody queried in ninety days should be questioned.
Start with the question, not the tool
The choice between a lake and a warehouse is really a question about certainty. If you know what you will ask and you need the same answer every time, model it and put it in a warehouse. If you are collecting material for questions you have not formed yet, dump it in a lake and revisit it when the question shows up.
For most newsrooms, that means both — a small, well-governed warehouse for the numbers people quote in meetings, and a patient lake for everything else. Pick one source, one question, and one owner this week. The architecture can grow from there.
Photo: heladodementa / Pixabay
