Redshift data sharing lets one warehouse (the producer) expose live tables to another (the consumer) without copying. The consumer queries the producer's data with its own compute, sees committed changes as they happen, and never receives a file. In a multi-account organization this replaces the nightly export-and-load job between the central data platform and each business unit's warehouse, and it is the basis of the common "one RA3 producer, many Serverless consumers" architecture.
This guide walks through the cross-account case: producer in account 111111111111, consumer in account 222222222222, both RA3 or Serverless (DC2 nodes cannot share). Same-account sharing is the same minus the authorization step.
On the producer: create and populate the datashare
-- Producer namespace, database "warehouse"
CREATE DATASHARE finance_share;
ALTER DATASHARE finance_share ADD SCHEMA finance;
ALTER DATASHARE finance_share ADD TABLE finance.gl_entries;
ALTER DATASHARE finance_share ADD TABLE finance.cost_centers;
ALTER DATASHARE finance_share ADD ALL TABLES IN SCHEMA finance; -- alternative: everything
-- Optionally let the consumer see tables added to the schema later
ALTER DATASHARE finance_share SET INCLUDENEW = TRUE FOR SCHEMA finance;
You can also add views, materialized views, late-binding views and user-defined functions. What you cannot do is grant write access on a regular datashare; consumers are read-only (multi-warehouse writes are a separate feature with its own datashare type).
If the consumer may be publicly accessible, the datashare must say so explicitly, otherwise the association will fail:
ALTER DATASHARE finance_share SET PUBLICACCESSIBLE = TRUE;
Leave this FALSE unless you need it.
Grant the share to the consumer account
GRANT USAGE ON DATASHARE finance_share TO ACCOUNT '222222222222';
For a consumer namespace in the same account you would grant to a namespace ID instead:
GRANT USAGE ON DATASHARE finance_share TO NAMESPACE 'c1d2e3f4-...';
Check what has been granted:
SELECT share_name, consumer_account, consumer_namespace, share_type
FROM SVV_DATASHARE_CONSUMERS;
Authorize the cross-account grant
A cross-account grant in SQL is only a request. The producer account must authorize it at the AWS API level, which is the control point for organizations that want a security team, not a DBA, to approve data leaving the account.
# Run in the PRODUCER account
aws redshift authorize-data-share \
--data-share-arn arn:aws:redshift:us-east-1:111111111111:datashare:abcd1234-.../finance_share \
--consumer-identifier 222222222222
The datashare ARN is in SVV_DATASHARES on the producer (share_arn column) or in describe-data-shares.
On the consumer: associate and create the database
The consumer account now sees the share as available. Associate it with a specific namespace (or all namespaces in the account):
# Run in the CONSUMER account
aws redshift associate-data-share-consumer \
--data-share-arn arn:aws:redshift:us-east-1:111111111111:datashare:abcd1234-.../finance_share \
--consumer-arn arn:aws:redshift-serverless:us-east-1:222222222222:namespace/9876fedc-...
Then, in the consumer warehouse, turn the share into a local database:
SELECT share_name, producer_account, producer_namespace
FROM SVV_DATASHARES
WHERE share_type = 'INBOUND';
CREATE DATABASE finance_shared
FROM DATASHARE finance_share
OF ACCOUNT '111111111111' NAMESPACE 'abcd1234-...';
GRANT USAGE ON DATABASE finance_shared TO ROLE analysts;
Query it like any other database in the namespace, using three-part names:
SELECT cc.department, DATE_TRUNC('month', g.posted_on) AS month,
SUM(g.amount) AS total
FROM finance_shared.finance.gl_entries g
JOIN finance_shared.finance.cost_centers cc ON cc.id = g.cost_center_id
WHERE g.posted_on >= '2026-01-01'
GROUP BY 1, 2
ORDER BY 1, 2;
The consumer can also create views and materialized views over the shared tables in its own database, which is how you add local joins and pre-aggregations without touching the producer.
Permissions inside the share
Granting the datashare gives the consumer namespace access; who inside the consumer can read it is controlled by normal Redshift permissions on finance_shared. The producer can also apply row-level security and dynamic data masking policies to shared tables, and they are enforced on the consumer side, so one share can serve several consumers with different visibility.
Chargeback patterns
The consumer pays for its own compute; the producer pays for storage. That aligns incentives well, and it makes chargeback straightforward:
- One consumer namespace per team (typically a Serverless workgroup with its own tags). The team's bill is its RPU-hours, visible in Cost Explorer by tag, and
SYS_SERVERLESS_USAGEin each namespace. - Producer side, use
SVL_DATASHARE_USAGE_PRODUCERto see which consumers are scanning which objects and how much; this is the basis for allocating the producer's storage and any Concurrency Scaling cost. - Consumer side,
SVL_DATASHARE_USAGE_CONSUMERshows what the namespace pulled from each share.
-- Producer: scans by consumer over the last 30 days
SELECT consumer_account, consumer_namespace,
COUNT(*) AS requests, SUM(bytes) / 1073741824.0 AS gb_scanned
FROM SVL_DATASHARE_USAGE_PRODUCER
WHERE request_time > DATEADD(day, -30, GETDATE())
GROUP BY 1, 2
ORDER BY gb_scanned DESC;
Operations notes
- Cross-region sharing is supported for RA3 and Serverless; the producer pays for cross-region data transfer, so put that in the chargeback model.
- Adding objects to a share is live; consumers see new tables immediately if
INCLUDENEWis on, otherwise when you add them explicitly. - Revoking is
REVOKE USAGE ON DATASHARE ... FROM ACCOUNT ...on the producer, followed by deauthorizing in the API. Consumers' queries fail cleanly afterwards. - Data sharing to AWS Data Exchange uses the same mechanism for selling or publishing data to third parties.
If you are designing a multi-account data platform and want the producer/consumer topology, the permission model and the chargeback worked out before the first share is created, that is what our Data Modeling & Architecture and Lakehouse services cover.