Baidu built an MPP analytical database called Palo for its ad reporting business and open-sourced it in 2017; it was donated to the Apache Incubator in July 2018 as Apache Doris and graduated as a top-level project in June 2022. Your lakehouse already answers the same aggregate questions in 20 to 60 seconds. What workload property justifies a second storage tier at all and where would copying this be a mistake?

The situation that produces this decision

Advertiser reporting is the demanding shape of analytics: thousands of external users, each querying their own slice, interactively, during the working day, over data that keeps changing. Nobody waits 40 seconds for their own campaign numbers, and each user's query is small. That is a concurrency and latency workload, and it is the opposite of what a lake is optimised for.

The deciding property

Queries per second against a bounded set of aggregates, with a latency target under a second.

The mechanism is a per-query floor. A lakehouse query pays metadata planning, listing the files that survive pruning, opening remote objects over the network, and starting tasks - a fixed cost of hundreds of milliseconds to seconds that is irrelevant at 10 queries a minute and dominant at 500 a second. Elastic compute does not remove it; every query pays it again.

A serving tier removes the floor instead of scaling past it: resident processes, data on local storage in a pre-sorted and often pre-aggregated form, and a query path with no planning negotiation. You are not buying more throughput, you are buying a lower fixed cost per query.

What it costs

A second system holding a second copy of the data, with its own capacity planning, failure modes and upgrade path. A loading path from the lake that can fall behind, adding a freshness gap to explain. Less flexibility - arbitrary joins across raw history are what the lakehouse is for, and they do not belong here. And the discipline that the serving tier holds only the serving model: the moment it becomes a second source of truth, the two tiers disagree and the lake stops being authoritative.

The organisational decision in this case is separable and instructive. Open-sourcing and then donating the project moves the maintenance burden into a foundation with outside contributors, at the price of losing control over the roadmap. Running an internal fork of an analytical database is a standing team.

Where copying it would be a mistake

• Internal BI. Four hundred analysts with a five-second tolerance is not this workload. A result cache plus a decent layout gets there, and both are already paid for.
• Unpredictable exploration. Pre-aggregation buys nothing when the next query's grain is unknown, and the serving tier becomes an expensive copy.
• A team without operators for a stateful cluster. This is a distributed database to run, rebalance and upgrade, and the cost is people rather than licences.

The test: external-facing or embedded analytics with a sub-second latency commitment and concurrency in the tens to hundreds of queries per second justifies a serving tier. Everything else is a cache and a clustering key away, and those are reversible in a day.

Common weak answers

• "The lakehouse is slow so add a faster engine." Thirty seconds for an analyst's ad-hoc scan is not slow; it is the wrong workload for the tier. The question is always which workload, not which engine is faster.
• "Scale the lakehouse compute up." More compute shortens the scan and leaves the per-query floor intact, so p99 at high concurrency barely moves while the bill does.
• "Use the open-source project because a large company built it." The provenance tells you the workload it was built for, which is the useful signal. It tells you nothing about whether you have that workload.