What Optus says it has built
Das said Optus uses Confluent's Oracle CDC (Change Data Capture) connector and Oracle's LogMiner with its Kafka streaming platform. That combination pulls 400 tables out of Oracle and feeds them into Databricks. He described Databricks as the home for "the analytical use cases, the reporting use cases" and, "most important right now," the regulatory use cases. Accuracy matters most for that last group.
The headline claim concerns speed. Das said that preparing accurate data for Optus leadership and other parts of the business used to take two or three days. It now takes hours. The aim is a dependable view of how the business performed over the previous 24 hours. He said this "was not possible two years back."
Beyond reporting, Das listed two further uses:
- In-store behaviour tracking: Optus can follow customer behaviour in its stores in near real time. That could support marketing offers based on purchase behaviour.
- Machine learning and AI: Das said the data could be put to wider ML and AI use because it is no longer locked in legacy silos.
These are described as capabilities and opportunities. The reporting doesn't show that specific AI applications or personalised offers are already running.
Why CDC and LogMiner matter
Confluent's documentation says its Oracle CDC Source connector captures each change to rows in a database and represents the changes as change event records in Apache Kafka topics. It uses Oracle LogMiner, Oracle's built-in redo log mining utility, to read the database redo log. The connector also requires a database user with permissions to use LogMiner and to select from all of the tables captured by the connector.
This is a different approach from polling. One third-party explainer from Platformatory argues that query-based polling usually depends on columns such as LAST_UPDATED_DATE, can miss deletes and certain updates, and usually adds read load on source tables. That is an outside view, not something Optus has said. It does show why log-based capture suits a use case where accuracy is the main concern.
Confluent's marketplace listing adds some prerequisites. The connector requires supplemental logging with "ALL" columns. Its listed supported versions are Oracle 11g, 12c, 18c, and 19c. That listing is 127 days old in the search index, so check current documentation before planning a deployment. The listing also says it is a premium connector that needs a separate subscription. For anyone budgeting a similar project, that is a real line item.
The Azure and Databricks platform behind it
iTnews reports that Optus recently finished a major transformation. It stood up a unified data platform (UDP) with a consortium of Microsoft, Databricks and Tech Mahindra. The UDP brings data from across the business into a data lakehouse on Azure. Databricks provides the analytics and governance layer that controls how the data is used.
Optus CIO Mark Potter spoke to the iTnews Podcast when the platform went operational. He said the transformation would run in two phases:
- A lift-and-shift away from a data warehouse nearing end-of-life.
- Consolidation of "two other very substantial data marts", which was then expected to finish this year.
Potter also said some data would stay outside the UDP and be brought in only when needed. His words were: "We're driving a high degree of data consolidation, but we're not executing a strategy of one data mart for the entire organisation." These are launch-era plans. The reporting doesn't confirm which consolidations are finished.
Das said Confluent's streaming is already playing a "key role" in the transformation. He expects the wider stack to change or be simplified, but he sees the "bus layer" that moves data into the platform as the part where Confluent stays significant.
What the reporting doesn't say
The claims are strong, but the evidence behind them is limited. Everything here comes from Optus's own representative at a vendor event. iTnews doesn't publish independent measurements. Several details are missing:
- Latency: "Near real-time" has no stated number. Treat it as a description, not a service level.
- Regulations: The article doesn't name the rules involved or any deadline. It also doesn't say whether the stream itself is a regulatory report.
- Accuracy: There is no explanation of how accuracy is validated or reconciled against Oracle. Nothing is said about handling initial loads, schema changes, replay, backlogs or duplicate events.
- Oracle's future: The reporting doesn't say Optus is moving off Oracle. The approach looks more like a bridge that frees the data than a replacement.
Speed also doesn't equal compliance. Faster, fresher data helps teams produce accurate answers sooner. Governance, validation and process still decide whether those answers are right.
Takeaways for IT teams
- Legacy databases don't have to be migrated before their data becomes useful. Log-based change capture can feed a cloud lakehouse while the source system keeps running.
- A "unified" platform can still be selective. Optus is deliberately leaving some data outside the UDP.
- Plan around the connector's prerequisites. These include supplemental logging, a suitably privileged database user, a premium subscription and a supported Oracle version.
- The streaming layer is treated as separate from the analytics stack. Das expects the stack to change while the data-movement layer stays, so the integration choice may outlast the platform choices.
Optus's account shows a Microsoft-hosted lakehouse working alongside a vendor-neutral streaming layer. Whether the "days to hours" improvement holds up is something only Optus's own metrics can show.