Day: July 2, 2026

Rethinking the Analytics Stack: An OCI-Native Pattern for ETL and BI Workloads

The dominant pattern for enterprise analytics today combines a lakehouse platform with a cloud BI tool, typically hosted on a hyperscaler that may sit outside the enterprise’s primary cloud estate. For organisations whose operational systems and data gravity have shifted to Oracle Cloud Infrastructure, this raises a sharper question than “should we migrate?” It becomes “which workloads belong on OCI, and which should stay where they are?” An OCI-native ETL and BI pattern – built on managed change data capture, streaming, Spark, lakehouse storage, and an OCI-resident BI layer – is now a credible substitute for the lakehouse + cloud-BI stack for specific workload profiles. The substitution is partial, not wholesale, and recognising the difference is what separates a well-judged migration from an expensive one. The Shift We’re Seeing For most of the last decade, analytics architecture decisions defaulted to a familiar pairing: a lakehouse platform on one hyperscaler, a cloud BI tool from another. The pattern worked well, and for many enterprises it still does. But three shifts are causing more organisations to revisit the assumption. First, data gravity is moving. As ERP, CRM, and other systems of record consolidate onto Oracle infrastructure, particularly Autonomous Database and the broader OCI estate, the cost and latency of pulling operational data into a hyperscaler-hosted lakehouse is no longer marginal. Cross-cloud egress, network configuration overhead, and the operational complexity of bridging identity and governance models across two clouds add up. Second, multi-cloud cost pressures are intensifying. Finance teams asking pointed questions about cloud spend rarely accept “we run on two hyperscalers because that is where the tools are” as a sufficient answer. Third, OCI’s native analytics services have matured to the point where ETL and BI workloads no longer require a hyperscaler-hosted platform to be served well. That changes the calculation. None of this argues for wholesale platform replacement. It argues for workload-level scrutiny. The Workload-by-Workload Question The temptation, when a platform decision feels overdue, is to ask “should we move to OCI?” This framing produces poor decisions, because the right answer is rarely uniform across all the things the platform does. A modern analytics platform is not one workload; it is a portfolio. ETL pipelines, BI serving, data science notebooks, ML training and serving, GenAI workloads, governed data sharing, each has different requirements, different maturity expectations, and different switching costs. Treating them as a single migration target ignores the most important question: which of these workloads is OCI ready to host well today, and which is not? The positioning below frames this more usefully than a platform-level yes or no: Figure 1 — Workload positioning. The OCI-native pattern fits where data gravity is on OCI and the workload is ETL or BI; other quadrants warrant a different decision. The pattern that follows in this article addresses the top-left quadrant – ETL and BI workloads for enterprises whose data gravity is Oracle- or OCI-aligned. For these workloads, OCI’s native services now offer a coherent end-to-end pipeline that performs the same role the dominant lakehouse + cloud-BI stack performs elsewhere. The other quadrants matter, but they are not the subject of this article, and that distinction is intentional. Data science and ML workloads especially those leaning on unified catalog governance, integrated MLOps tooling, or specialised query accelerators have more capability gaps on OCI today and deserve a separate evaluation. Conflating the two slows the decisions enterprises can confidently make. The OCI-Native ETL and BI Pattern The pattern moves data from operational systems to analytics consumers through five logical stages: change capture, event buffering, transformation, lakehouse storage, and BI serving. Figure 2 — OCI-native ETL and BI pipeline. Lakehouse storage (yellow) is the strategic anchor: an open table format that decouples data from compute. Change Data Capture. The pipeline begins with a CDC engine that streams committed changes from the source system in near-real-time. For Oracle-resident sources, Oracle GoldenGate is the strongest fit – its integrated capture via redo logs is low-impact on the source and well-suited to transactional consistency requirements. For non-Oracle sources, the CDC tool should be re-evaluated per source; the rest of the pattern downstream is source-agnostic, which is one of its quieter strengths. Event Buffering. CDC events land in OCI Streaming, a Kafka-compatible managed service that acts as the event bus for the pipeline. This decoupling matters more than it first appears. It separates ingestion velocity from transformation velocity, allows multiple downstream consumers – analytics, operational integrations, audit – to read the same change stream independently, and provides the replay capability needed to recover from downstream failures without re-extracting from the source. Transformation. OCI Data Flow, a managed Apache Spark service, consumes events from the streaming layer and applies transformations in micro-batches. PySpark provides the flexibility to express complex business logic, slowly-changing dimensions, late-arriving data handling, and quality controls that no-code transformation tools tend to struggle to articulate cleanly. The compute layer is managed; the consumer does not operate the cluster. Jobs scale up for backfill workloads and scale down for steady-state ingestion. Lakehouse Storage – the Strategic Anchor. Bronze and Silver layers land in OCI Object Storage as Delta tables. Gold-layer aggregates land in Oracle Autonomous Data Warehouse for BI-optimised access. This split is deliberate. The Bronze and Silver layers, written in an open table format, are portable by construction – they are not locked into a proprietary engine, and any future change in compute or query technology does not require re-landing the raw data. The Gold layer in the warehouse provides the query performance, security model, and operational maturity that BI consumers expect. Enterprises that prefer a simpler topology can collapse all layers into the warehouse; enterprises that anticipate broader data platform requirements should retain the open lakehouse layers. BI Serving. The final stage is BI consumption from the Gold layer through an OCI-native analytics service. The advantage here is connectivity: no cross-cloud gateway, no hybrid network configuration, no shared-credential plumbing between separate clouds. Reporting authentication, row-level security, and semantic modelling live within the same identity boundary