Data Sharing From Autonomous Database: Delta Sharing Support

Every estate we assess has a shadow distribution network. A finance warehouse exports a CSV every Monday for a partner. An analyst refreshes a spreadsheet extract for a sister company. A nightly job dumps tables to an SFTP server nobody has audited since the person who built it left. Each of these is a data sharing requirement that was real enough to solve, solved with the only tool available at the time, a copy. Copies go stale, copies escape governance, and copies multiply storage and risk in equal measure.

The structural fix is to share access instead of copies, and the OCI data platform now has two native mechanisms for it. Delta Sharing support in Autonomous Database publishes data over an open protocol that non Oracle consumers, Databricks, Spark, Python, Power BI among them, can read directly. Cloud Links handle the Oracle to Oracle case inside OCI with even less ceremony. Together they cover most sharing requirements that used to be solved with exports, and this article walks through how each works, what they cost, and the cases where an older mechanism is still the right call.

The provider and recipient model

Delta Sharing is an open protocol originally published by Databricks and now supported across the lakehouse ecosystem. Its model is deliberately simple. A provider publishes a share, a named collection of tables. A recipient is granted access to that share and receives an activation credential. From then on the recipient queries the shared data with any client that speaks the protocol, and the provider's side controls exactly what is visible, to whom, and for how long.

Autonomous Database implements both sides. As a provider, you select schemas and tables, define the share, create recipients, and send each one an activation link that delivers a credential file. As a recipient, Autonomous can consume shares published by other Delta Sharing providers, including non Oracle ones, so data arriving from a partner who runs Databricks lands as queryable external tables without a single pipeline being built.

Two details matter operationally. First, shares of object storage backed data are versioned: the provider publishes a new version when the data changes, and recipients read a consistent snapshot rather than a moving target. Second, recipient credentials carry expiry and can be revoked at any moment, which is precisely the control a CSV on an SFTP server never had. Revoking access to a copy is impossible. Revoking access to a share is one statement.

Cloud Links for the Oracle to Oracle case

Delta Sharing earns its keep when the consumer is outside the Oracle world. When both sides are Autonomous Databases in the same OCI tenancy or region, Cloud Links are the lower friction path. A publisher registers a table or view with a scope, the registering database decides who may subscribe at tenancy, compartment, or specific database level, and consumers discover and query the data in place with standard SQL. No credential files, no protocol endpoints, no copies. Access rides on OCI identity, which means it inherits the IAM boundaries your Autonomous Database estate already enforces.

The practical division of labour is clean. Internal sharing between Oracle databases inside the platform: Cloud Links. Sharing with partners, customers, or internal teams on Spark, Databricks, Python, or BI tools: Delta Sharing. Both beat the export pipeline they replace.

The full menu of sharing mechanisms

Delta Sharing and Cloud Links join a set of older mechanisms that each still have a place. The honest comparison looks like this.

The table makes the decision mostly self evident. Exports survive only for genuine one off handoffs. Database links persist where they already exist but should not be the pattern for new work, since their credential model is coarse and their blast radius is wide. Replication through GoldenGate remains correct when the consumer genuinely needs a local, writable, continuously synchronised copy, which is an integration requirement rather than a sharing requirement. Everything else belongs on a share.

What it costs

The sharing features themselves are included in Autonomous Database. What you pay for is the infrastructure underneath: the database OCPUs that serve queries, the object storage holding versioned share data, and the egress when recipients pull data out of the region. That last line deserves attention. A share consumed heavily by an external recipient in another cloud generates outbound transfer, and while OCI egress pricing is far gentler than the competition's, a chatty consumer pulling full snapshots hourly is a cost pattern worth catching in design rather than on the invoice. We cover the wider discipline in designing a data platform that does not leak money.

Versioned shares also accumulate storage. Each published version persists until pruned, so a share republished daily on a large table needs a retention decision, how many versions back a recipient might reasonably read, written down and enforced, exactly like a backup policy.

Governance is the point, not a feature

The reason to move sharing onto these mechanisms is not convenience, it is control. A share has an owner, a recipient list, an expiry, and an audit trail. That makes data sharing reviewable in the same way access to the database itself is reviewable. The pattern we implement for clients pairs shares with OCI Data Catalog so that what is shared, with whom, and why is discoverable alongside the rest of the estate's metadata, and lineage shows which upstream pipelines feed shared tables. When a regulator or a security review asks who outside the organisation can see customer data, the answer becomes a query, not an archaeology project.

Row and column controls still apply. Shares expose tables and views, and the view is the right unit of sharing in most cases: it lets you project away sensitive columns, filter rows to the recipient's entitlement, and keep the physical schema private. Sharing base tables directly is the lazy default that turns into a redaction project later.

A six step framework for standing up data sharing

Limits worth naming

Delta Sharing from Autonomous is snapshot oriented for object storage backed shares, so a consumer needing second by second freshness is a replication use case, not a sharing one. The protocol moves data over HTTPS, which is fine for analytical pulls and wrong for bulk synchronisation of terabytes on a tight schedule. Cloud Links stop at the Oracle boundary. And no sharing mechanism fixes unmodelled data: publishing a confusing schema to a partner just exports the confusion. The sequencing that works is model first, share second, which is the same order that makes a lakehouse architecture succeed.

Bringing it together

Data sharing used to be a choice between governance and practicality, and practicality always won, in the form of copies. Delta Sharing support in Autonomous Database and Cloud Links inside OCI remove the excuse: live or versioned access, revocable credentials, audit trails, and consumers free to use the tools they already run. The work is less about the features and more about the migration discipline, finding the shadow exports, wrapping entitlements in views, and actually decommissioning the copy paths. That is a contained project with a measurable end state, and it is one we run regularly inside wider platform engagements, on a fixed project fee, with an assessment as the starting point to size the export inventory and the quickest wins.