Data warehouse vs data lake vs lakehouse: which healthcare data architecture fits?
Health systems, payers and health tech teams choosing an analytics platform hear three answers: a data warehouse, a data lake or a lakehouse, with data mesh added on top. The right one depends on the data types you hold, how you separate identified and de-identified PHI, the size of your team and the questions the data must answer.
Data lake vs data warehouse vs lakehouse: which fits each healthcare workload?
Quick answer
A lakehouse is usually the safer default once notes, images or FHIR exports enter the picture, because it keeps raw files and governed tables in one store with clear PHI zones. A data warehouse still fits a small team running quality measures and claims reporting on structured data. Agnotic Technologies designs either around PHI zones from the start.
| Criterion | Warehouse | Lakehouse |
|---|---|---|
| Quality measures and regulatory reporting | Strong fit: modelled tables and SQL | Fits once curated tables are built; a plain lake does not |
| Claims analytics on 837 and 835 data | Strong fit after parsing and modelling | Fits, and keeps the raw files for reprocessing |
| Operational dashboards | Strong fit for structured, refreshed data | Fits through curated tables; check query speed |
| Machine learning on notes and images | Poor fit: text and images sit outside the model | Strong fit: raw files and tables in one store |
| Research cohorts on de-identified data | Fits in a separate de-identified schema | Fits in a separate de-identified zone with its own access |
| FHIR Bulk exports | Needs flattening before load | Land the NDJSON files raw, then build tables |
| Team size and skills | Small SQL team | Data engineering skills for storage, formats and jobs |
| Schema changes from source systems | Planned table changes before new data loads | Raw data lands first; table formats handle column changes |
What they are
What is Warehouse
A warehouse stores structured, modelled tables and checks data against a schema when it is written. It suits SQL reporting on claims, encounters and quality measures, and is the simplest pattern for a small team, but it handles notes, images and nested FHIR data poorly.
What is Lakehouse
A data lake keeps raw files of any type in low-cost object storage and applies a schema when data is read. A lakehouse adds an open table format on top, so the same storage also serves governed tables with transactions and schema changes. A plain lake without that layer is hard to govern for PHI.
Key differences
What do schema on write and schema on read mean for health data?
A warehouse applies the schema when data is written, so bad records fail at load and reports stay consistent. A lake applies the schema when data is read, so anything can land, including notes and images, and structure is applied by each job. A lakehouse keeps both: raw files for anything, and governed tables for reporting.
Is data mesh a fourth option?
No. Data mesh is an operating model: domain teams, such as claims, clinical or pharmacy, own and publish their data as products under shared rules. It runs on top of a warehouse or a lakehouse. It suits large organizations with several data teams and adds coordination cost for a small one.
How should PHI zones be laid out?
Use at least three zones. A raw zone holds identified source data and only pipeline jobs and a few engineers can read it. A curated zone holds modelled identified data for named roles; 45 CFR 164.514(d)(2) requires a covered entity to identify the people or classes of people who need access and the categories of PHI each needs. A de-identified zone holds data that meets 45 CFR 164.514(b), through expert determination or the safe harbor method, for research and wider analytics.
Which healthcare formats land where?
FHIR Bulk exports arrive as NDJSON, the format the Bulk Data Access guide requires servers to support, and should land raw before flattening. HL7 v2 messages and X12 835 and 837 files land raw, then are parsed into tables. DICOM images and clinical notes stay as files in the lake with their metadata in tables. Our ETL vs ELT guide covers where those transforms run.
What does an open table format add to a data lake?
Transactions and safe schema changes. The Apache Iceberg table specification describes serializable isolation, where readers always see a committed snapshot and writes are never partially visible, and schema evolution that supports adding, dropping, reordering and renaming columns. For PHI, that means a failed job cannot leave half-written data in a curated table.
When to use each
When to use Data warehouse
- Most of your data is structured: claims, encounters, labs and enrollment.
- Your main outputs are quality measures, financial reports and dashboards.
- A small analytics team works mainly in SQL.
- You do not yet hold notes, images or large FHIR exports.
When to use Lakehouse
- You hold notes, images, device data or FHIR Bulk exports alongside claims.
- Data science teams need raw data for machine learning on text or images.
- You need to keep raw source files to rebuild tables later.
- Several engines, such as SQL and notebooks, must read the same data.
How do you move from a data warehouse to a lakehouse?
1. Keep the warehouse running. Reports and quality measures continue unchanged while the lakehouse is built beside it.
2. Land raw data first. Point source feeds at the raw zone as well as the warehouse, so new data is captured in both.
3. Rebuild one domain at a time. Start with the domain that needs raw data most, often notes or FHIR exports, and build its curated tables.
4. Reconcile before switching. Run the same measures on both platforms and investigate every difference.
5. Move reports domain by domain, then retire warehouse tables once nothing reads them.
6. Set zone access and audit logging before the first identified data lands, not after.