Amazon Redshift data sharing lets one warehouse, the producer, expose selected live database objects to another warehouse, the consumer. The consumer queries producer data without making a second copy. This guide walks through a read-only share between two warehouses, then covers cross-account and cross-Region access and the separate write-sharing feature. See the Amazon Redshift data sharing overview for the full set of supported patterns.

The SQL examples assume the producer database already contains a schema named public and a table named orders. Replace the example names and namespace IDs with values from your own warehouses. If you are new to Redshift databases and queries, start with our Amazon Redshift first-steps guide.

Check prerequisites

Data sharing works between separate Amazon Redshift provisioned clusters and Serverless workgroups. Provisioned clusters must use supported RG or RA3 node types; a Serverless consumer namespace must have a workgroup associated with it so users can run queries. Provisioned and Serverless warehouses can share with each other. Confirm that both warehouse types and the selected Region are supported in the current Region availability table.

Run producer-side SQL as a database superuser or database owner, or as a user with the required datashare privileges. The user adding objects must also own them or have the required object privileges. Creating a consumer database and granting access to local Redshift users or roles require consumer-side database permissions.

Record both warehouses' namespace GUIDs. Run this query once on each warehouse, or find the value in its namespace or cluster details in the Redshift console:

SELECT CURRENT_NAMESPACE;

Use the consumer GUID when the producer grants access to a namespace. Use the producer GUID when the consumer creates a database from that share. These identifiers are different.

Create a read-only datashare

Connect to the producer database that contains the objects you want to share. A datashare belongs to one database, and only objects from that database can be added. Create the share, add its schema, add the table, and grant access to the consumer namespace:

CREATE DATASHARE sales_share;

ALTER DATASHARE sales_share ADD SCHEMA public;
ALTER DATASHARE sales_share ADD TABLE public.orders;

GRANT USAGE ON DATASHARE sales_share
TO NAMESPACE 'consumer-namespace-guid';

Adding a schema does not automatically include the existing tables inside it, so add each object explicitly or use ADD ALL TABLES IN SCHEMA public to include the current tables and views. The ALTER DATASHARE ... ADD TABLE form grants the datashare read access to that object. Redshift also supports adding supported views and SQL user-defined functions. See AWS's ALTER DATASHARE reference for object types and privileges.

To include objects created in a schema later, a superuser can enable INCLUDENEW for that schema:

ALTER DATASHARE sales_share
SET INCLUDENEW = TRUE FOR SCHEMA public;

This setting applies to future tables, views, and SQL UDFs in that schema; it does not add existing objects. Review the schema's data before enabling it because later objects will also become available to consumers.

Create and query the consumer database

On the consumer warehouse, create a local database that points to the datashare. Use the producer namespace GUID from the earlier query. The WITH PERMISSIONS option lets you grant consumer users or roles access to only the objects they need:

CREATE DATABASE shared_sales
WITH PERMISSIONS
FROM DATASHARE sales_share
OF NAMESPACE 'producer-namespace-guid';

Assuming the consumer role analytics_readers already exists, grant it access to the database and its shared schema and table. Connect to a local database when running these grants:

GRANT USAGE ON DATABASE shared_sales TO ROLE analytics_readers;
GRANT USAGE ON SCHEMA shared_sales.public TO ROLE analytics_readers;
GRANT SELECT ON shared_sales.public.orders TO ROLE analytics_readers;

The role can then query the shared table with ordinary SQL:

SELECT *
FROM shared_sales.public.orders
LIMIT 10;

If you omit WITH PERMISSIONS when creating the database, granting a user or role USAGE on that database gives it access to every object in the shared database. Choose that simpler model only when all database consumers should see all shared objects. AWS documents both models in CREATE DATABASE and GRANT.

Share across accounts or Regions

Within the same AWS account, grant access directly to the consumer namespace as shown above, including when the warehouses are in different Regions. For cross-account sharing, grant access to the consumer account ID instead:

GRANT USAGE ON DATASHARE sales_share
TO ACCOUNT 'consumer-account-id';

Cross-account sharing has an AWS account-level approval step as well as Redshift database permissions. After the producer grants access to the consumer account, a producer account administrator must authorize the datashare in the Redshift console. A consumer account administrator then associates the incoming datashare with the whole account, a supported Region, or specific consumer namespaces. For least-privilege access, select only the namespaces that need the share. Once associated, the consumer database administrator can create the database using the producer account ID and producer namespace. Replace consumer-account-id and producer-account-id with their respective 12-digit account IDs:

CREATE DATABASE shared_sales
WITH PERMISSIONS
FROM DATASHARE sales_share
OF ACCOUNT 'producer-account-id'
NAMESPACE 'producer-namespace-guid';

For same-account cross-Region sharing, use the namespace-grant flow above and confirm that both Regions support data sharing. For cross-account cross-Region sharing, select the intended supported consumer Region when associating the share. Cross-Region queries can incur data transfer charges for the consumer. Check the cross-account workflow and cross-Region workflow for current console steps and availability.

Encryption requirements depend on the sharing boundary. For two warehouses in the same AWS account, both must use the same encryption state: both encrypted or both unencrypted. Across accounts, both producer and consumer warehouses must be encrypted. They do not need to use the same KMS key. Redshift encrypts shared data in transit. Serverless namespaces are encrypted by default. Review the data sharing encryption considerations before configuring the share.

Separate the permission layers and inspect a share

There are three distinct permission checks:

  • Producer datashare access: GRANT USAGE ON DATASHARE makes a share available to a consumer namespace or AWS account.
  • Consumer database access: SQL GRANT statements control which Redshift users and roles can query the database and objects created from the share.
  • AWS administration: IAM policies control which AWS identities can use the console and Redshift management APIs. IAM permissions do not replace the Redshift SQL grants above.

On the producer, use SHOW DATASHARES to list shares and DESC DATASHARE sales_share to inspect the objects in this share. The console shows consumers and cross-account authorization status. On the consumer, confirm that the share is available and that the database was created in the namespace associated with a workgroup or cluster.

To remove an object or revoke a consumer's access, use ALTER DATASHARE ... REMOVE or REVOKE USAGE ON DATASHARE on the producer. Removing access prevents the consumer from querying the share. For cross-account sharing, also review or remove the account authorization and consumer association in the console.

Optional: enable multi-warehouse writes

A standard datashare is read-only unless the producer explicitly grants write privileges. Amazon Redshift now supports multi-warehouse writes: for example, a producer can grant a share INSERT access to a table. This is a separate design from the read-only setup above; a datashare is not made writable by adding a WRITE_ACCESS option to CREATE DATASHARE.

GRANT INSERT ON TABLE public.orders TO DATASHARE sales_share;

Grant only the operations and objects the consumer requires. Write sharing has additional requirements, including supported RG or RA3 provisioned clusters or Serverless workgroups and snapshot isolation for the producer database. AWS currently documents support from patch 186 (provisioned current-track version 1.0.78881 or later) and Serverless version 1.0.78890 or later. For cross-account writes, the producer must authorize write access and the consumer must associate specific clusters or workgroups for writes. Review AWS's multi-warehouse write setup and write limitations before enabling this capability.

Troubleshoot common access problems

  • The share is missing on the consumer: confirm that the producer granted access to the right consumer namespace or account. For cross-account access, verify producer authorization and consumer association; for cross-Region access, check that the selected Region supports data sharing.
  • The database exists but a query is denied: confirm the database, schema, and object grants on the consumer. With WITH PERMISSIONS, USAGE on the database alone does not grant access to tables.
  • An object is missing: confirm it belongs to the database tied to the datashare and was added to the share. Adding a schema alone does not add existing objects; INCLUDENEW covers future supported objects only.
  • Cross-account access fails: confirm both warehouses are encrypted, the account-level share is authorized and associated, and the consumer used the producer account ID and namespace in CREATE DATABASE.
  • A client cannot run a query: verify it can connect to the consumer endpoint and that its Redshift user or role has the required SQL grants. Producer and consumer warehouses do not need direct VPC or security-group connectivity to each other for data sharing.

Next steps

Start with a narrowly scoped, read-only datashare, explicitly list its objects, grant the consumer namespace access, and give consumer roles only the database and object permissions they need. Add cross-account or cross-Region access only after checking the account handshake, Region availability, and encryption requirements. Treat writes as a separate capability with its own privileges and operational constraints.

If your Redshift tables are populated by an ETL workflow, see our guide to automating Redshift ETL with AWS Glue. For the full Redshift SQL and console procedures, use the linked AWS data sharing documentation as the current reference.