The lakehouse is a
primitive, not a product
The trade press is full of lakehouse coverage right now, and for good reason. Databricks and Snowflake are converging on essentially the same architecture from different starting points. Apache Iceberg has won the open table format question. The shape of enterprise data infrastructure for the next decade is genuinely settling — toward a pattern that combines the schema discipline of a warehouse with the storage flexibility of a lake, sitting on open formats you can rebuild your tooling around without migrating your data.
This is real architecture. It solves real problems. If you run data engineering at a Fortune 500 company, the lakehouse is probably the right answer to most of the questions you are being asked.
If you run technology at a hotel group with twelve properties, or thirty, or seventy, it is not. It looks like the right answer because it is the architecture being talked about. It is the wrong answer for a structural reason that is easy to miss, and the cost of getting it wrong is usually a two-year detour and a quietly abandoned BI initiative.
The thing the lakehouse vendors are actually selling — and they will tell you this if you ask, though their marketing softens it — is infrastructure primitives. A way to land data into open table formats. A query engine. A catalog. A governance layer. Tools that an internal data engineering team uses to build the company’s data platform. The lakehouse is not the platform. It is the substrate from which a platform gets constructed.
The lakehouse is not the platform. It is the substrate from which a platform gets constructed.
The hidden assumption in every lakehouse pitch is that the customer has a data engineering team. The pitch says “open architecture” and “best-of-breed tooling,” and what it means in operational terms is: you will hire data engineers, you will hire a platform engineer, you will hire an analytics engineer, you will likely hire consultants for the first eighteen months, and the architecture will pay off after that initial investment because your team will have built something tailored to your business.
For a Fortune 500 company, this trade is fine. The team already exists or can be hired. The tailoring is genuinely valuable. The eighteen-month build amortises against decades of ongoing operation.
For a hotel group with thirty properties, the trade is catastrophic. The team does not exist. It cannot easily be hired, because the regional labour market for senior data engineers is thin and what exists is being absorbed by large enterprises. The tailoring is not, in fact, valuable — because every other group of similar size needs roughly the same things: same KPIs, same source systems, same operational questions, same governance constraints. The eighteen-month build does not amortise against decades; it amortises against five to seven years of operation before the next technology lead arrives and rebuilds everything.
What the assembled thing
actually looks like
The gap between a lakehouse and what hotel groups need is not a single layer of abstraction. It is two.
Layer 1 — The canonical model
The schema that defines what an entity is in your domain. A hotel group needs entities for properties, reservations, stays, guests, outlets, channels, content, signals. Not generic tables you might map onto, but a schema designed by people who understand that a stay is not a reservation, that a folio is not a payment, that a channel manager’s view of a booking is structurally different from a PMS’s view of the same booking. Building this correctly takes deep domain knowledge and several months of dedicated work. A lakehouse gives you the tools to build it. It does not give you the schema.
Layer 2 — The semantic model
The encoded definitions of every metric, segment, and operational concept that someone in the business will ask about. RevPAR. ADR. Net ADR after distribution costs. Channel contribution. Displacement. Pace. Segment definitions. Stay value. Attach rate. Each has a canonical computation, and getting them slightly wrong is how BI projects end up producing answers the commercial team and the operations team disagree about. A lakehouse gives you SQL access to your data. It does not give you a semantic layer where every KPI is encoded once and queried by everyone consistently.
A hotel group buying a lakehouse and then trying to populate these two layers is not unreasonable in principle. It just is not a plan that fits the people, time, or budget the group actually has. The first layer alone — the canonical schema — is a category of work that data platform vendors typically wave at and customers typically underestimate by a factor of three. By the time the group has spent six months arguing internally about whether a complimentary breakfast voucher is part of folio revenue or a marketing cost, the project has already failed.
What hotel groups need is a product where these two layers are already done. Where the schema is opinionated and tested. Where the KPIs are encoded. Where adapters for the source systems they actually run — Cloudbeds, Mews, Opera, SiteMinder, D-EDGE — already exist. Where the privacy and governance posture is baked in rather than configured. Where the thing you connect to your source systems on Monday produces useful intelligence on Friday, because all the architectural work that would have taken eighteen months has been done by someone else, once, and is now sold as a product.
That product category does not currently have many vendors. The enterprise chains build their own version on top of platforms like the lakehouse, with internal teams of dozens. The application layer is well-served: there are PMS vendors and CRM vendors and revenue management vendors and channel managers, all selling individual workflow tools. The infrastructure layer underneath those applications — where canonical data lives and the semantic layer sits — is empty for everyone below the enterprise chain scale. That is the gap.
Vertical,
not horizontal
The shorthand for this distinction is vertical infrastructure versus horizontal infrastructure.
Horizontal infrastructure is what the lakehouse vendors sell: tools that work for any industry, any data shape, any use case, designed to be flexible because their customers are heterogeneous. The flexibility is the value, but the flexibility is also the cost — flexibility means the customer has to do the configuration, the schema design, the KPI encoding, the adapter development.
Vertical infrastructure is the same architectural rigour applied to a single industry’s actual data shape. The schema is hospitality-shaped. The semantic layer encodes hospitality KPIs. The adapters target hospitality source systems. The governance posture reflects hospitality regulation. The customer does not get flexibility; they get a finished product. They give up the optionality of building something custom, and in return they get a system they can adopt rather than construct.
At the ten-to-a-hundred property scale, customisation is a cost, not a benefit.
The trade is correct for a structural reason: at the ten-to-a-hundred property scale, customisation is a cost, not a benefit. The hotel group’s data shape is not actually different in important ways from a peer group’s. What feels custom is mostly a function of which PMS the group runs, which channel manager, which loyalty platform — and these are all things adapters handle. The actual operational reality of a thirty-property group in Andalucía and a forty-property group in Quintana Roo is more alike than it is different.
A vertical product gets to make assumptions a horizontal one cannot. It can encode the segment definitions every group disputes for six months internally, because the encoded definition is good enough and the cost of disagreement is higher than the cost of accepting a reasonable convention. It can ship with a recipe library — the structured investigations groups actually run — already authored, because the questions are common across the industry. It can be a finished product because the industry’s variability is smaller than its internal politics suggest.
The pattern is
older than it looks
This is not a new shape, just a new instance of one. Every horizontal infrastructure category eventually grows vertical successors above it. Cloud compute grew Heroku, then Vercel, then a hundred more focused PaaS products that work for narrower use cases. CRM grew vertical CRMs for legal practices, real estate brokers, and dental groups. Even within data, dbt sits above the warehouse because most teams building inside a warehouse needed transformation tooling shaped for them rather than primitives they had to assemble themselves.
The lakehouse is the latest horizontal substrate. It is doing what horizontal substrates do: winning the architectural argument for organisations that need flexibility. The next phase, already starting, is the construction of vertical products on top of it for industries whose customers do not need flexibility and cannot operate primitives.
Hospitality is one of those industries. The products that win this vertical will not be lakehouse vendors going down-market — that pattern almost never works, because the cost structure is wrong — and they will not be application vendors going up-market. They will be purpose-built firms taking the architectural rigour that has been earned in the horizontal layer and applying it where the customer can actually consume it.
This is what we are building at Studio Oriente, with a product called Meridian: hospitality data infrastructure for independent and regional hotel groups. A canonical schema, an encoded semantic layer, adapters for the systems groups actually run, and a governance posture built for the industry — delivered as a finished product rather than a construction kit.
The question
worth asking now
If you run technology at a hotel group at this scale, the question is not “should we adopt the lakehouse pattern that everyone is writing about?” Almost certainly you should not. The question is: what is the right level of abstraction for our scale and our team?
If your answer is “the lakehouse,” you are committing yourself to becoming a data platform engineering shop. That is a coherent strategic choice. Some groups at this scale should make it. Most should not.
If your answer is “we need finished hospitality intelligence that plugs into the systems we already run,” then the lakehouse is not your answer. It is also not a question you should be litigating internally. The lakehouse is the conversation a different industry is having with itself, and it is the right conversation for them. The conversation that fits your scale is one layer up and one layer over.
The lakehouse moment is useful as a prompt. It forces clarity about what you actually need. It is not, for most hotel groups, useful as an answer.