# Delta Sharing: a REST protocol for handing out tables without copying them

> Delta Sharing is an open REST protocol plus a Python connector, a Spark connector and a reference server for sharing a slice of a cloud dataset with consumers on other compute platforms. The data stays in the provider's bucket; the consumer gets a profile file and a table URL.

**delta-io/delta-sharing** — An open protocol for secure data sharing

- Repository: https://github.com/delta-io/delta-sharing
- Website: https://delta.io/sharing
- Stars: 960 · Forks: 242
- Language: Scala
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/delta-io-delta-sharing

## Why share a table instead of copying it

Delta Sharing is described as an open protocol for secure real-time exchange of large datasets, and the mechanism is deliberately narrow: a REST protocol that shares access to part of a cloud dataset and moves the bytes through modern cloud storage systems such as S3, ADLS or GCS. The provider publishes once, the consumer connects, and nobody has to run the provider's compute platform to read the result.

The intended audience is any organisation that holds data in a lakehouse but serves consumers who work elsewhere. A team on Databricks can share a table with analysts who only have pandas installed, and the analyst pulls rows through the connector without provisioning a cluster. The README lists pandas, Tableau, Apache Spark and Rust among the systems that can connect to shared data, and describes the consumer experience as starting to use the data in minutes.

That framing also tells you what the protocol is not. There is no synchronisation or replication step described, no write path, and no notion of a subscriber maintaining its own copy. If your problem is keeping two copies in step, this is the wrong protocol.

## What the repository actually ships

The repository holds four things, and the split matters for how you adopt it. First, the protocol specification itself, in PROTOCOL.md, which defines the REST calls, the profile file format and the table URL scheme. The repository also carries a YAML description of the protocol API, delta-sharing-protocl-api-description.yml.

Second, a Python Connector, a library that implements the protocol and reads shared tables into a pandas DataFrame, or into a Spark DataFrame when running under PySpark with the Spark connector present. Third, an Apache Spark Connector that reads shared tables from a Delta Sharing Server and exposes them to SQL, Python, Java, Scala or R.

Fourth, a reference server implementation, described as being for development purposes. It can be deployed to share existing tables in Delta Lake and Apache Parquet format sitting on cloud storage. The build file is build.sbt with a version.sbt and a project directory, so the Scala side of the project is the server and the Spark connector, with client, cli, spark, server and python directories at the top level.

The practical consequence: the server is not a finished commercial product. You can stand one up to try the protocol, and the producer side you would pair it with is the part you likely already own.

## Installing the Python connector and the Rust wheel wrinkle

The Python package installs from PyPI. Python 3.8 or newer is required for version 1.1 and above, and older versions run on Python 3.6. On Linux the README also asks for glibc 2.31 or newer, which matters because the package pulls in a native wrapper.

```bash
pip3 install delta-sharing
```

The complication is delta-kernel-rust-sharing-wrapper. If the automatic installation of that wrapper fails, the README lists four checks in order: confirm python3 is at least 3.8, upgrade pip3, confirm the Linux glibc version is 2.31 or above, and install Rust. When glibc cannot be upgraded, or no pre-built wheel exists for the target environment, pip builds the package from source and Rust must be present. The README points at the PyPI files page for the wrapper to see which environments have a pre-built wheel.

There is a documented escape hatch. A version before the wrapper was baked into the installation can be pinned directly:

```bash
pip3 install delta-sharing==1.0.5
```

And if you would rather build the wrapper yourself, the README documents a virtual environment with maturin:

```bash
cd [delta-sharing-root]/python/delta-kernel-rust-sharing-wrapper
python3 -m venv .venv
source .venv/bin/activate
pip3 install maturin
maturin develop
```

That fallback path is a real part of the operational story: a Python 3.8 plus Linux machine with an old glibc needs a compiler and a Rust toolchain on top of the normal install.

## Profile files and table URLs are the whole user interface

Access starts with a profile file, a JSON file holding a user's credentials for a Delta Sharing Server. Three routes to one are described: download a profile file for an open example server the maintainers host, stand up your own reference server and write a profile file against it, or receive a profile file from the data provider.

The connector then turns a profile file plus a table name into a table URL. The naming convention is the profile file path followed by a # and the fully qualified table name in the form share-name.schema-name.table-name. Here is the shape of the quick start:

```python
import delta_sharing

# Point to the profile file. It can be a file on the local file system or a file on a remote storage.
profile_file = "<profile-file-path>"

# Create a SharingClient.
client = delta_sharing.SharingClient(profile_file)

# List all shared tables.
client.list_all_tables()

# Create a url to access a shared table.
# A table path is the profile file path following with `#` and the fully qualified name of a table
# (`<share-name>.<schema-name>.<table-name>`).
table_url = profile_file + "#<share-name>.<schema-name>.<table-name>"
```

Note the comment about the profile file being allowed on remote storage. That is the only hint in the README about how the profile reaches a consumer in a locked-down environment, and it is a hint rather than a documented credential distribution scheme.

## Reading a shared table, and the flags that change the read

Two loading functions do the work. load_as_pandas pulls rows into a pandas DataFrame and, with a limit argument, reads a small number of rows so you can sample a table that does not fit in memory. load_as_spark does the same under PySpark, returning a Spark DataFrame.

```python
delta_sharing.load_as_pandas(table_url, limit=10)
delta_sharing.load_as_pandas(table_url)
delta_sharing.load_as_pandas(table_url, use_delta_format=True)
delta_sharing.load_as_pandas(table_url, convert_in_batches=True)
delta_sharing.load_as_spark(table_url)
```

The four pandas calls differ in what the connector does under the hood. Passing limit=10 fetches a sample. Passing use_delta_format=True asks the connector to read using Delta format explicitly. Passing convert_in_batches=True uses batch conversion, which the comment describes as potentially reducing memory usage.

Two optional features deserve attention. The connector can take a jsonPredicateHints argument, a JSON document with an op of equal, a column named hireDate of valueType date and a literal value of 2021-04-29 in the example, which pushes a filter down rather than filtering after the read. The second is change data feed: if the table supports history sharing, which the README ties to tableConfig.cdfEnabled=true on the OSS Delta Sharing Server, the connector can query table changes. That last detail is a server capability rather than a client option, so it only helps if the provider enabled it.

## Where the protocol hits its limits

The clearest limit is that this is a read path. Nothing in the repository describes writing shared tables back, so a consumer that can read a table cannot amend it, and a provider that wants a write-back loop needs something else.

The second limit is server side. The server in this repository is explicitly a reference implementation for development purposes. The list of formats it can share is narrow: existing tables in Delta Lake and Apache Parquet format on modern cloud storage systems. Other formats on the provider's side are not covered by what the README describes.

The third limit is network topology. Because the data transfer runs over the cloud storage layer rather than through the server, a consumer needs to reach the underlying bucket, not only the server endpoint. That is easy to overlook on a laptop reading an open example dataset and painful in a corporate network with egress rules. The README does not describe a proxy or a caching tier for this case.

A fourth limit is the binary dependency described earlier. glibc, Python version and the presence of Rust all become part of your support matrix, which is not something a pure REST protocol would normally impose.

## Compared with handing out credentials or exporting files

The usual alternative to a sharing protocol is to give the consumer credentials for the storage bucket and let them read it with whatever library they like. The difference in approach is where the policy lives. With direct credentials, the consumer can read anything in the bucket that the credentials permit, and revoking access means rotating keys. With Delta Sharing, the provider hands out a profile scoped to a server, the server exposes a set of shares, and a table URL names one table inside one share.

Another alternative is a periodic export: copy the table to a customer bucket, or deliver it as files on a schedule. That gives the consumer a stable, self-contained copy and works across any network, but it costs storage, it goes stale, and someone has to run the copy. Delta Sharing trades the copy for live reads, which suits data that changes often and is queried by someone who should not own a duplicate.

For teams that need the data in their own warehouse, the Spark connector's ability to expose shared tables to SQL, Python, Java, Scala or R is the point of the project, and a plain export would not need a protocol at all.

## Release cadence, the Apache-2.0 licence, and what an upgrade involves

The repository is not archived and the last push was on 2026-10-19, so work on the code base is current. Recent tags show the protocol and the Python package moving on separate tracks: version 1.4.1 of Delta Sharing on 2026-07-22, version 1.4.0 on 2026-05-06, and Python package 1.4.2 on 2026-08-12. Separate versioning means the Python connector is not automatically the same revision as the server, and pinning both is a reasonable habit.

The upgrade cost is not only the pip install. The Python 3.8 and glibc 2.31 requirements, the delta-kernel-rust-sharing-wrapper dependency and the pinned older fallback at 1.0.5 all belong to the compatibility story, and the README documents the fallback because wheels do not exist for every environment. A team on an old Linux image may find that the safest path is the older package rather than the newest one.

The licence is Apache 2.0, with the text in LICENSE.txt. It is permissive and includes the standard patent grant and notice obligations. The protocol specification in PROTOCOL.md sits under the same licence, which matters for anyone writing their own server implementation rather than deploying the reference one.

## Conclusion

Take Delta Sharing when the data owner keeps the data in cloud object storage and the consumers want to read it without a Spark cluster, a copied extract, or a shared account. Do not take it when the provider must run real queries over complex joins, when the consumer needs write access, or when the network path between the two sides cannot reach the underlying bucket. Verify three things before you commit: that your Delta Lake or Parquet tables are reachable through the reference server's storage layer, that the profile file format your provider hands out matches the connector version you pin, and that the platform-specific caveats in the release notes for v1.4.1 and py-v1.4.2 do not change the read path you depend on.

## FAQ

### How do I install the Delta Sharing Python connector?

Run pip3 install delta-sharing. You need Python 3.8 or newer for version 1.1 and above, and on Linux glibc 2.31 or newer for the delta-kernel-rust-sharing-wrapper dependency, otherwise pip builds it from source and Rust must be installed.

### How do I read a shared table with Delta Sharing in pandas?

Point the connector at a profile file, create a SharingClient, build a table URL by appending # and the share.schema.table name to the profile path, then call delta_sharing.load_as_pandas with that URL. Pass limit to sample rows, or convert_in_batches=True to reduce memory usage.

### Can I write to a table shared through Delta Sharing?

The protocol and the connectors described in the README cover reading shared tables only. Nothing in the repository describes a write or write-back path.

### What is the Delta Sharing Server in this repository?

It is a reference implementation server for the Delta Sharing Protocol, described as being for development purposes. It can be deployed to share existing tables in Delta Lake and Apache Parquet format on modern cloud storage systems.

### Can Delta Sharing consumers query table changes?

Yes, if the table supports history sharing. The README ties this to tableConfig.cdfEnabled=true on the OSS Delta Sharing Server, and the connector can then query table changes.

## Sources

- [delta-io/delta-sharing on GitHub](https://github.com/delta-io/delta-sharing)
- [License: Apache-2.0](https://github.com/delta-io/delta-sharing/blob/main/LICENSE)
- [Project website](https://delta.io/sharing)
- [README](https://github.com/delta-io/delta-sharing/blob/main/README.md)
- [Releases](https://github.com/delta-io/delta-sharing/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/delta-io-delta-sharing