A packed lunch is a convenient way to feed one person. But if you're preparing a buffet for two hundred people, opening individual lunchboxes and sorting their contents into serving trays is an inefficient way to serve the same food.
The food hasn't changed; its arrangement has. Food already grouped by dish could be ready to serve in minutes. Unpacking and sorting two hundred meals could take hours.
Data systems face the same tradeoff. Keeping an order's details together helps you find or change that order. Calculating sales across millions of orders calls for a different arrangement.
We'll use the kitchen to explain what databases, warehouses, lakes, and lakehouses do, how they fit together, and which work each one helps you do.
Operational databases: the packed lunch
Label a lunchbox with someone's name, and you can hand them their meal without visiting every tray on the buffet. Everything for that serving is packed together.
A row-oriented database uses a similar arrangement. Each row holds the fields for one record. In an orders table, that might include an order number, customer ID, date, and delivery status. Keeping those values together suits work focused on individual orders: opening one or changing its delivery details.
An index is the list telling you which shelf holds each person's lunchbox. You know exactly where to go and which box to pick, without opening boxes to check what's inside. An index on an order number gives the database the same shortcut: it points to the matching row without having to search through every order.
Each lunchbox can carry a customer number that matches an entry in a customer register. The meal stays in the box; the customer's contact details stay in the register. A database relationship works the same way: each order stores a customer ID that links to the customer's record. If their phone number changes, you update it once rather than changing every order they've placed.
Suppose someone changes their lunch order from chicken to a vegetarian meal. That means updating their order, putting the chicken meal back into available stock, and reserving a vegetarian meal. Those changes need to happen together so the order and the available meals stay in agreement. A transaction groups them into one update: either every change is saved, or none is. If one part fails, the database undoes the other changes in that transaction, leaving the original order intact.
Operational databases are built for this kind of work: finding individual orders and making reliable changes to them.
Now ask how much broccoli went into every lunch last year.
You have to open box after box to measure the broccoli, even though you don't need the sandwiches or desserts. Row-oriented storage can involve the same extra work: reading the rest of each record to get the one field you want to total. Indexes can help with some questions, but this arrangement is built around keeping each order together.
Data warehouses: the prepared buffet
At the buffet, the food is grouped by type rather than packed into individual meals. All the broccoli is together in one tray, the sandwiches in another, and the desserts in another. You can measure the broccoli across hundreds of servings without opening everyone's lunch or handling the rest of their food.
Column-oriented storage groups values from the same field across records. To total sales, an analytical engine can read the relevant amounts without also reading delivery addresses and customer notes. Reading less unnecessary data helps with calculations over large datasets.
Now suppose you want one person's complete meal. You can grab their packed lunchbox in seconds. At the buffet, you might spend a few minutes visiting each tray to collect a sandwich, broccoli, and dessert. You end up with the same meal, but you have to assemble it yourself.
Retrieving a whole record from column-oriented storage can mean gathering its fields from several places, just like collecting a meal from separate trays. This arrangement helps when you want a few fields across many records. Keeping a record together helps when you want that individual record. The actual speed depends on the system.
A data warehouse is the prepared buffet: data brought together and made ready for reporting. Arranging the trays is part of the job. Preparing their contents so people can use them together is another.
Preparation matters as much as arrangement. Putting a bag of uncooked rice on the buffet won't help anyone looking for lunch. Similarly, placing sales and refund records next to each other doesn't produce a reliable revenue report. Someone must connect the records and decide how refunds affect the calculation. Processing tools apply those rules to prepare the tables people query.
The analyst can then work from agreed definitions instead of reconciling the sources for every report. Those tables still need checks and updates as the business changes.
Data lakes: the pantry
The buffet holds food prepared for a particular meal. Behind it, the kitchen needs somewhere to keep ingredients for everything else it might make. That's the pantry: labeled spice jars, washed broccoli, and a crate from the farmer's market that still needs sorting. You can keep those ingredients without deciding exactly which dish each one will go into.
A data lake gives you that kind of storage for files. Data arriving from different systems can be kept in its original form before you've worked out how to combine it for a report. JSON from an application, scanned invoices, and cleaned datasets can all sit in the same lake, just as unopened deliveries and prepared ingredients can share the pantry.
The deliveries can arrive in different packaging. Two suppliers might send readable JSON files but use different field names or record quantities in different units. Processing software does the sorting and preparation: reading those files, matching the fields, and converting the units. It can save the prepared results alongside the originals, so you can go back to a source invoice if a quantity was read incorrectly.
Some of that stock benefits from more organized containers. Parquet is a file format that groups values by column, using the same arrangement we saw with the buffet. It lets analytical software read the fields it needs from a file. The lake is the pantry; Parquet is one way to pack what's on its shelves. The Parquet article explains those file mechanics in more detail.
A neatly labeled jar can still contain the wrong spice. Saving data as Parquet organizes its storage, but checking quantities and reconciling product names remain part of preparation. A lake can hold both incoming files and data ready for analysis; how much preparation each needs depends on what you want to make with it.
Keeping that pantry useful takes care: label where each delivery came from, when it arrived, and where it belongs. For a lake, that means organizing files and recording their source and purpose so someone else can find and use them. As people add and replace files, keeping track of what's current becomes a separate job.
Lakehouses: adding inventory management
Now several cooks are using the pantry at once. A delivery arrives during a stock count. Someone replaces a batch while another person prepares dinner. Labels tell you what's in each container, but you also need a dependable record of what's current.
A collection of Parquet files has a similar coordination problem. Which files make up a table? Which ones have been replaced? What should a reader see while an update is in progress?
Delta Lake adds inventory records and rules for changing them. Its transaction log tracks which Parquet files make up each version of a table. Software that supports Delta uses this log to save a complete update and let readers work from a consistent version while changes are underway. It can also enforce a table's schema—the defined columns and their data types—so incoming data follows the expected structure.
Suppose a supplier sends a corrected invoice. Processing code matches it to the original records and uses Delta to save the replacement as one table update. Readers can see a complete version rather than a mix of old and replacement records. The code still has to identify the right invoice; the inventory system records the change, but someone has to choose the correct batch.
Knowing which ingredients are available doesn't prepare the meal. A query engine reads the data, filters records, and performs calculations. A lakehouse combines those analytical tools with lake storage and table management. The pantry stays in place, equipped with inventory management and the tools to work from it. Delta supplies one possible table-management layer; the engine does the processing.
The unsorted market delivery can still sit alongside carefully labeled supplies. A lakehouse can contain incoming files as well as prepared tables for reporting. Its managed tables let people analyze data over lake storage without requiring a separate warehouse copy of every dataset.
A warehouse and a lakehouse can both provide prepared tables for reporting. The choice depends on how you bring data in, how you need to change it, and which tools your team uses to analyze it. Both approaches still need the preparation we saw at the buffet: matching records, agreeing on definitions, and checking the results.
Choosing the setup
Start with the work you already do. If your database handles orders and reports comfortably, that may be enough. When reporting slows order updates, or each report requires reconciling several sources, a warehouse gives that analytical work a separate place to run.
A lake is useful when you need to retain varied source files and reuse them for different questions. If you also need coordinated table updates and analytical queries over that storage, a lakehouse brings those capabilities together. These pieces can work together, and you can introduce the ones your workload needs.
Before adding another piece, name the work it needs to improve. Finding one order quickly, comparing a year of sales, and correcting a table while others query it are different requirements. Decide what you're serving before rearranging the kitchen.