The short answer
Historically, sharing data between distinct business units or external partner teams required exporting data to S3 files, transferring them across accounts, and loading them into target databases. This introduced data latency, increased storage costs, and created multiple conflicting versions of the truth.
Redshift Data Sharing enables live, secure, zero-copy sharing of schemas, tables, views, and user-defined functions across Redshift clusters, AWS accounts, and AWS regions.
+----------------------------+
| Producer Cluster (ETL) |
| Writes data to RMS / S3 |
+----------------------------+
|
| metadata share grant (Zero data copy!)
v
+----------------------------+ +----------------------------+
| Consumer Cluster (BI Team) | | Consumer Cluster (Finance) |
| Read-only queries directly | | Read-only queries directly |
| against Producer RMS | | against Producer RMS |
+----------------------------+ +----------------------------+How it works under the hood
Data Sharing is made possible by the decoupled storage architecture of Redshift RA3 nodes.
- Producer defines a datashare: The producer administrator creates a DATASHARE object and adds specific schemas or tables to it.
- Authorization: The producer authorizes specific consumer AWS account IDs or cluster namespaces.
- Consumer creates a database: The consumer administrator creates a local database from the datashare reference.
When a query runs on the consumer cluster, the consumer's compute nodes read the data blocks directly from the producer's Redshift Managed Storage layer over high-speed AWS internal networking.
The consumer cluster pays for its own query compute. The producer cluster experiences zero CPU or memory degradation from consumer queries, achieving complete workload isolation.