Four Paradigms of StarRocks Lakehouse Integration and an Overview of StarRocks 3.0

The article introduces the concept of lake‑warehouse (lakehouse) integration and presents four main sections: the need for integration, its difficulties, StarRocks' four integration paradigms, and a preview of StarRocks 3.0.

Why lake‑warehouse integration is needed – Data lakes provide low‑cost, reliable storage using object storage (S3, OSS, COS) and support various file formats (Iceberg, Hudi, Delta Lake). Integrating a warehouse on top of the lake reduces storage costs, improves table and file formats, offers a unified catalog, and enables better data governance.

Challenges of lake‑warehouse integration – Unifying metadata and DDL, providing real‑time capabilities, and achieving warehouse‑level performance on top of a lake are the three core difficulties addressed by StarRocks.

Four StarRocks lake‑warehouse paradigms

1. Query acceleration on the data lake – StarRocks acts as a high‑performance query engine with local cache, delivering 3‑6× speedup over traditional lake queries.

2. Layered lake‑warehouse modeling – Using ODS‑DWD‑DWS‑ADS layers, external tables and materialized views simplify data pipelines and enable high‑concurrency reporting.

3. Real‑time warehouse‑lake fusion – Kafka‑ingested data is stored in StarRocks and periodically flushed to the lake, providing second‑level freshness and unified SQL access.

4. StarRocks 3.0 cloud‑native lakehouse – A storage‑compute separated architecture built on StarOS offers multi‑AZ high availability, elastic scaling, and reduced storage costs.

The article also previews StarRocks 3.0 features such as storage‑compute separation, enhanced RBAC, simplified partition syntax, full UPDATE support, and operator spill‑to‑disk.

Finally, a Q&A section addresses metadata caching, local cache behavior, and the expected release timeline for StarRocks 3.0 (RC01 end of March, GA in April).