Building a Lakehouse on OCI: Object Storage Plus ADB

The data warehouse and the data lake spent a decade as rival religions. The warehouse offered governed, fast SQL over curated data, at the price of loading everything first and paying warehouse rates to store it. The lake offered cheap storage for everything in any shape, at the price of becoming, in most organisations, a swamp nobody could query with confidence. The lakehouse is the armistice: keep the data in cheap object storage, keep it in open file formats, and bring governed, fast SQL engines to the data instead of moving the data to the engine. On OCI the pattern is concrete and inexpensive: Object Storage holds the lake, Autonomous Database and HeatWave query it in place, and the supporting services handle movement and governance. This article is the architecture guide.

The lakehouse is the storage backbone of the OCI data platform, so if you are placing this piece in the wider estate, start with the pillar and come back.

Warehouse, lake, lakehouse

The last row is the strategic one. In a lakehouse the durable asset, your data, sits in files you control in formats any engine can read. Engines become choices rather than commitments, which changes your negotiating position with every vendor involved, including Oracle.

The OCI building blocks

Object Storage as the lake

OCI Object Storage provides the storage layer: durable, regional buckets with lifecycle policies that move aging data to Infrequent Access and Archive tiers automatically. Lakehouse capacity costs object storage prices, which are a fraction of database storage prices, and the lifecycle automation means history gets cheaper as it cools without anyone filing a ticket. Bucket structure, naming, and tiering policy are design decisions, not defaults, and they are covered by the broader storage standards in our OCI storage practice.

Open formats as the contract

The lake earns the house suffix through file formats. Parquet is the workhorse: columnar, compressed, splittable, and readable by every engine that matters. Table formats above it, Iceberg in particular, add transactional semantics, schema evolution, and time travel over collections of Parquet files. The rule that keeps a lakehouse honest is that data lands in open formats from the start. Proprietary detours reintroduce the lock in the architecture exists to avoid.

Engines over the lake

OCI's distinctive move is letting its flagship databases query the lake in place. Autonomous Database reads object storage through external tables, so curated lake data joins warehouse tables in one SQL statement, with the database's full security model applied. HeatWave Lakehouse loads object storage files into its in memory cluster and scans them at engine speeds that embarrass most dedicated warehouses, a capability we examine closely in HeatWave Lakehouse. For transformation rather than serving, Spark through OCI Data Flow reads and writes the same buckets serverlessly. Three engines, one copy of the data, zero loading pipelines between them.

Zone design: raw, curated, serving

Working lakehouses are zoned. The raw zone receives data exactly as it arrived, immutable, organised by source and arrival time, the place audits and reprocessing start from. The curated zone holds cleaned, deduplicated, conformed data in Parquet or Iceberg, organised by domain, the place analysts and engines actually query. The serving zone holds shaped outputs, aggregates, features, and extracts tuned for specific consumers. Data flows one way through the zones, every transformation is repeatable code rather than manual surgery, and nothing queries raw except the processes that curate it. Teams that collapse the zones to save effort recreate the swamp with extra steps.

Getting data in, and knowing what you have

Ingestion is the rest of the platform doing its job: GoldenGate streams database changes into the lake continuously, Data Integration lands batch extracts on schedule, and Streaming delivers events, each covered in its own article in this series. The governance side is non negotiable at lake scale: OCI Data Catalog harvests metadata from buckets and databases alike, so the curated zone stays discoverable and lineage stays traceable. We cover the habits that keep that true in OCI Data Catalog, and the catalog should be live before the second data source lands, not after the fortieth.

Security and access in a lakehouse

A lakehouse changes the security question. In a warehouse, the engine enforces access; in a lakehouse, the files are reachable below any engine, so the design has to close that door deliberately. On OCI the pattern is layered. At the storage layer, IAM policies scope bucket access to the services and pipelines that need it, with human read access to raw and curated zones treated as the exception requiring justification, not the default. Pre authenticated requests and public buckets have no place in a lakehouse. At the engine layer, consumers query through Autonomous Database or HeatWave rather than reading files directly, which restores row level controls, masking, and auditing exactly where people touch the data. At the encryption layer, customer managed keys in OCI Vault cover the buckets for estates whose regulators ask who holds the keys. The principle that organises all three layers is simple: humans meet data through governed engines, services meet data through scoped policies, and nobody meets the raw zone casually.

A seven step build framework

Bringing it together

A lakehouse on OCI is not a product purchase, it is a small number of disciplined decisions: object storage as the single store, open formats as the contract, zones as the structure, a catalog as the memory, and engines chosen per workload over the same files. Estates that hold those lines get warehouse quality answers at object storage prices and keep every future engine choice open. Estates that improvise get a swamp with a nicer name. If you want the first outcome with fewer detours, an OCI assessment turns this architecture into a concrete design for your sources, your consumers, and your budget.