A shared table can replace a file feed—but only if you choose the right change semantics

Databricks has published a two-part implementation guide for replacing recurring file and API feeds with OpenSharing. The useful lesson is not simply “read instead of copy.” It is that a shared table offers several different consumption contracts, and an analytics or data-agent pipeline must choose one deliberately.

Three paths that are easy to confuse

In the implementation walkthrough, a provider publishes a Delta table WITH HISTORY and a Databricks recipient reads it through Structured Streaming. A durable checkpoint records how far the reader has progressed, while Trigger.AvailableNow processes currently available changes and stops. Databricks also documents a table-update trigger for starting a job after the provider commits new data.

That is an incremental landing pattern, not automatically a complete replication contract. The walkthrough says its ignoreChanges path can re-emit rows and does not propagate deletes. A consumer that needs inserts, updates and deletes must instead read the table’s Change Data Feed. For Databricks-to-Databricks recipients on Runtime 19 or later, the post says automatic Change Data Feed can compute row-level changes at query time when row tracking is enabled.

The third path is not materializing a recipient copy at all. OpenSharing leaves the source data in provider storage and lets the recipient query the shared table. Databricks’ companion architecture post presents this as an alternative to SFTP exports, API polling and per-customer connectors, with table history available for backfills and provider-side system tables supplying an access trail.

What changes for data agents

For an agent or natural-language analytics service, these choices determine what “current data” actually means. A live shared-table query can see the provider’s current state. A checkpointed append pipeline sees changes only after its job runs and may encounter duplicate emissions. A CDC pipeline can preserve updates and deletions, but only if the provider exposes the required history and the recipient applies those events correctly.

That means freshness metadata should describe the consumption path, not merely the source table. An answer generated from a local materialization needs the checkpoint or last successful run alongside it. A system using append-only ingestion should not imply that deletions have propagated. And a backfill should be tested against retained table history rather than assumed to be recoverable forever.

The deployment checklist

Databricks’ guide recommends identifying whether the recipient is Databricks-to-Databricks or Databricks-to-Open, whether it needs a snapshot, incremental reads or row-level CDC, whether history is included, and how retries, duplicates, deletes and schema changes will be handled. It also recommends validating a minimal flow by creating a share, reading an initial snapshot, then inserting, updating and deleting a row and confirming the recipient observes the expected result.

That test is the practical control. “The table is shared” proves access. It does not prove that an agent’s downstream view is fresh, deletion-complete or replay-safe.