Before We Start: What This Post Is (and Very Much Isn't)

If you came here expecting a complete Amazon Redshift A-to-Z tutorial, I have bad news: your coffee can cool down now. ☕

This post is not a Redshift A-to-Z. This post deliberately focuses on one specific architectural problem, not a Redshift A-to-Z.

This post has exactly one job: to explain a very specific, very common moment of confusion in Amazon Redshift Serverless:

“We already have a Redshift Serverless workgroup attached to a namespace. We want another isolated workgroup with its own compute capacity, but we still want that new workload to query and JOIN the existing data. Can we attach the new workgroup to the same namespace?”

The short answer is:

No. A Redshift Serverless namespace and workgroup have a 1:1 relationship.

But there is a very useful second question:

“If we cannot attach two workgroups to one namespace, how can the second workgroup access the first namespace's data without copying everything?”

That's where Amazon Redshift Datashare enters the story.

That's the whole post. We'll cover:

1. What a namespace is.
2. What a workgroup is.
3. Why the namespace/workgroup relationship matters.
4. Why we cannot attach a second workgroup to the existing namespace.
5. Why Datashare exists, and what problem it's actually solving.
6. How a producer namespace and consumer namespace work.
7. How the consumer workgroup can query and JOIN shared tables.
8. A practical architecture for isolating compute while reusing existing data.
9. The important caveats and design considerations.

The goal is not to cover every Redshift feature. The goal is to make this one architectural puzzle crystal clear.

---

1. First, Meet the Two Characters: Namespace and Workgroup

Before discussing Datashare, we need to establish one mental model.

In Redshift Serverless, think of a namespace as the place where our data and database resources live, while a workgroup is the compute environment used to process queries against that data.

A simplified picture looks like this:

This distinction is the foundation for everything that follows.

---

What Is a Namespace?

A namespace is the collection of database objects and users. It owns:

• Our databases, schemas, and tables (the actual data)
• Users and permissions
• Encryption keys (KMS settings)
• Snapshots and backups
• Admin credentials

In short: the namespace is our data estate. It answers the question "what data exists, and who's allowed to see it?"

In other words: We can think of it as:

“This is where our Redshift data lives.”

---

What Is a Workgroup?

A workgroup is where the compute side of Redshift Serverless comes into play. It's the collection of database objects and users. It owns:

• RPUs (Redshift Processing Units) — the actual horsepower that runs our queries
• Network configuration — VPC, subnets, security groups
• The query endpoint our applications and BI tools connect to
• Usage limits and query queue configuration

In short: The workgroup is simply our compute unit. It defines our processing power and the network path to access it.

That's it. That's the whole primer. Now let's get to the actual drama.

---

2. The Plot Twist: Namespace and Workgroup Are 1:1

Here's the plot twist that catches almost everyone off guard the first time they try to scale out:

In Redshift Serverless, a namespace can be attached to exactly one workgroup, and a workgroup can be attached to exactly one namespace. Period.

It's a strictly monogamous, one-to-one relationship. Not one-to-many. Not many-to-many. One. To. One.

So here's the scenario that trips people up:

We already have a namespace — let's call it analytics-ns — happily paired with a workgroup called analytics-wg. Our analytics team has been querying away for months. Life is good.

Then a new team shows up — say, the fraud detection team. They need their own compute so their heavy queries don't compete with (or accidentally throttle) the analytics team's dashboards. Totally reasonable ask. So we think:

"Easy — we'll just spin up a new workgroup, fraud-wg, and point it at the existing analytics-ns namespace. Same data, dedicated compute. Done!"

And Redshift Serverless says: absolutely not.

We cannot attach a second workgroup to a namespace that already has one. If we want fraud-wg to exist as an isolated workgroup, it needs its own namespace — let's call it fraud-ns.

---

So Why Does AWS Enforce This?

AWS's own documentation doesn't spell out an explicit reason for why the pairing has to be strictly 1:1 — it simply states that namespaces and workgroups exist to let us isolate workloads and manage storage and compute separately. AWS doesn't publish a "here's exactly why it's one-to-one" explanation anywhere.

That said, the design makes a lot of sense once we think through what a workgroup and namespace together represent.

A. Compute isolation stays clean

A workgroup represents a compute environment with its own capacity and workload characteristics.

If multiple independent workgroups could freely attach to the same namespace, the relationship between data ownership and compute consumption would become considerably more complicated.

With 1:1, the mental model stays wonderfully simple:

Want another isolated compute environment?

We get another namespace/workgroup pair.

---

B. Cost and capacity stay easier to reason about

Redshift Serverless compute is expressed in RPUs, and usage limits can be configured for a workgroup.

Keeping the workgroup association unambiguous makes it much easier to answer questions like:

“Which workload is consuming this compute?”

and:

“Which workgroup should we scale or place a usage limit on?”

Now imagine several independent workgroups hanging off the same namespace.

Suddenly, the architecture starts looking less like a clean apartment building and more like a shared utility cupboard where everyone has plugged in their own extension cord.

The 1:1 model avoids that ambiguity.

---

C. Network configuration belongs to the workgroup

Workgroups carry compute-side configuration such as networking settings.

That separation is useful because the compute environment can have its own connectivity requirements without turning the namespace itself into a container for multiple competing compute/network configurations.

Again, the 1:1 relationship keeps the architecture easier to reason about:

---

D. The model gives us a clean ownership boundary

Perhaps the most useful way to think about the design is this:

• The namespace represents the data/database side
• The workgroup represents the compute side

AWS gives us a 1:1 relationship between them.

That makes the default architecture beautifully predictable:

But this creates an interesting problem.

What if we want another isolated compute environment while still working with the same data?

The obvious thing we'd like to do is:

Unfortunately, that's not how Redshift Serverless is designed.

The answer isn't to fight the 1:1 model.

The answer is to work with it:

• Create another namespace
• Create another workgroup

And then ask the really interesting question:

How do we let this new workgroup use the data that already lives in the original namespace — without simply copying the whole dataset?

That's where Datashare walks into the room.

---

3. If Namespaces Can't Be Shared, How Does Anyone Query Across Them?

This is where most people start Googling. Or, let's be honest, asking an LLM to save them from reading the docs.

The fraud team's new fraud-ns + fraud-wg pair is a totally empty house. No tables, no data, nothing. But the fraud team's queries absolutely need to JOIN against tables that live in analytics-ns — things like the master customers table or the transactions table.

Duplicating that data into fraud-ns is the obvious hacky workaround, and it's a bad one:

• Now we have two copies of the truth, which will drift out of sync
• We've doubled our storage costs
• Every schema change now needs to be replicated manually or via some fragile pipeline
• Our security team now has two places to audit permissions on the same sensitive data

This is exactly the gap that Datashare was built to close.

---

Enter Datashare: Finally, a Way Out of This 1:1 Nightmare

Redshift Datashare lets one namespace (the producer) share live, read-only access to specific databases, schemas, or tables with another namespace (the consumer) — without copying a single byte of data.

Crucially, here's the part that makes it click:

When the consumer namespace queries shared data, it does so using its own workgroup's compute capacity (RPUs) — not the producer's.

So the fraud team's fraud-wg uses its own dedicated RPUs to scan, filter, and JOIN against data that physically still lives in analytics-ns. The analytics team's compute is never touched. No contention, no duplication, no drift.

This is genuinely the elegant part of the design: Datashare decouples "who owns the data" from "who pays for the compute to query it." The producer keeps full ownership and governance. The consumer gets to run its own workload, on its own dime, on its own schedule — against live data, not a stale copy.

---

4. The Back Door: Sharing Data Without Sharing the Workgroup

Now let's stop talking about architecture diagrams and actually build the thing.

Our scenario is simple.

We already have:

And we want a completely separate compute environment for our fraud detection workload:

The catch?

Our fraud workload still needs to read some of the data owned by analytics-ns.

We can't attach fraud-wg to analytics-ns.

So instead, we create a second namespace/workgroup pair and use Datashare as the bridge.

Here's what we're about to build:

Let's open the back door.

Step 1 — Create the Datashare

First, we connect to the producer namespace, analytics-ns, through analytics-wg.

We create the datashare:

CREATE DATASHARE fraud_share;

Next, we decide exactly what our fraud workload needs to access.

In our example, that's just two tables:

ALTER DATASHARE fraud_share ADD SCHEMA public;

ALTER DATASHARE fraud_share ADD TABLE public.customers;

ALTER DATASHARE fraud_share ADD TABLE public.transactions;

That's an important detail.

We're not throwing open the entire namespace and shouting, “Come on in, everybody!”

We're explicitly choosing which objects cross the boundary.

The producer remains the owner of the original data.

The datashare simply defines what we're willing to expose.

---

Step 2 — Give the Consumer an Invitation

Creating the datashare isn't enough. We also need to tell Redshift which namespace is allowed to consume it.

Still on analytics-ns:

GRANT USAGE ON DATASHARE fraud_share
TO NAMESPACE 'fraud-ns-namespace-id';

Think of this as the guest-list check.

We're not giving the entire Redshift universe access to the share. We're explicitly granting our consumer namespace access.

---

Step 3 — The Consumer Accepts the Share

Now we switch sides.

We connect to the consumer namespace, fraud-ns, through its own workgroup, fraud-wg.

We create a database from the datashare:

CREATE DATABASE analytics_shared
FROM DATASHARE fraud_share
OF NAMESPACE 'analytics-ns-namespace-id';

And just like that, the shared data becomes available from the consumer side.

Conceptually, fraud-ns now has something like:

Notice what happened.

We didn't create another copy of the customers table just so our fraud workload could read it.

We're accessing the data owned by the producer through the share.

---

Step 4 — Now Let's Do Something Useful With It

This is where the whole architecture starts to pay off.

Suppose our fraud namespace has its own table:

fraud_detection.suspicious_activity

It contains:

transaction_id
customer_id
flag_reason

Meanwhile, the producer owns:

public.customers

with:

customer_id
customer_name
risk_score

Our fraud workload can now combine the two:

SELECT
    f.transaction_id,
    f.flag_reason,
    c.customer_name,
    c.risk_score
FROM fraud_detection.suspicious_activity f
JOIN analytics_shared.public.customers c
    ON f.customer_id = c.customer_id;

And this is the moment to pause and appreciate what's happening.

One side of the JOIN is native data in fraud-ns.

The other side is shared data owned by analytics-ns.

Yet the query is submitted through:

fraud-wg

and uses the consumer workgroup's compute environment.

The producer doesn't need to become the fraud team's compute engine.

The fraud workload doesn't need a second copy of the producer's entire dataset.

We have effectively achieved:

That's the back door.

We're respecting Redshift Serverless's 1:1 namespace/workgroup model instead of trying to work around it.

The second workgroup gets its own compute environment.

The producer keeps ownership of the original data.

And Datashare provides the controlled path between them.

---

5. What If We Decide to Move the Workload Later?

So far, we have solved the runtime isolation problem:

Datashare lets the second environment query data owned by the first.

But there is another very practical scenario worth covering.

What happens if, six months from now, we look at the workload and conclude:

“The existing workgroup has enough capacity. We don't need a dedicated workgroup for this application anymore.”

For example, imagine that the the application application starts like this:

Later, after measuring the workload, we decide that the existing environment can comfortably handle it:

existing_namespace namespace
        │
        ▼
existing_namespace workgroup
        │
        ▼
       32 RPU

There is an important catch.

We cannot simply point existing_namespace's workgroup at the new_app namespace.

The 1:1 relationship still applies.

So the question changes from:

“Can we move the workgroup?”

to:

“How do we move the data from the new_app namespace into the existing_namespace namespace?”

This is where Redshift gives us several options.

---

Option 1 — Datashare: Access the Data Without Moving It

The first option is Datashare.

We have already seen this pattern:

This is particularly useful if the immediate goal is to test the the application workload on the existing workgroup before physically moving the data.

The existing_namespace workgroup can query the shared the application data using its own compute.

That gives us a useful validation path:

But Datashare does not migrate the data

This distinction is important.

Datashare means:

“Keep the data where it is and let another namespace query it.”

It does not mean:

“Move the data into the other namespace.”

The source new_app namespace continues to own the underlying data.

That means Datashare is useful for:

• Workload validation
• Performance testing
• Temporary cross-namespace access
• Avoiding an immediate data copy

But if the final goal is:

new_app namespace
        │
        ▼
      gone

then Datashare alone is not enough.

The source namespace still needs to exist while it owns the shared data.

AWS documents Serverless data sharing here:

Amazon Redshift Serverless data sharing

There is also an important cost distinction: for data sharing, the consumer pays the compute required to query the shared data, while the producer continues to bear the underlying storage cost. For same-Region sharing, AWS does not charge cross-Region data-transfer fees because there is no cross-Region transfer. citeturn0search17

So Datashare can be an excellent bridge, but it should not be confused with a migration mechanism.

---

Option 2 — UNLOAD → S3 → COPY: Move the Data

If the goal is to actually move the the application data into the existing existing_namespace namespace, the most straightforward approach is:

This is the approach we would generally recommend for the consolidation scenario.

Step 1 — UNLOAD from the source namespace

From the new_app environment, we export the required data to Amazon S3.

For example:

UNLOAD ('SELECT * FROM new_app_schema.customers')
TO 's3://<migration-bucket>/rc-rosters/customers/'
FORMAT AS PARQUET;

We can control what gets exported using the SELECT statement.

That means we can migrate:

• Selected tables
• Selected columns
• Filtered data
• Transformed data, if required

Amazon Redshift writes the query results to one or more files in S3 and is designed to support parallel reloading of those files. citeturn0search5turn0search11

AWS reference:

UNLOAD — Amazon Redshift SQL Reference

---

Step 2 — Create the target tables

Before loading the data, we create the required schema and table definitions in existing_namespace.

For example:

CREATE SCHEMA new_app_schema;

CREATE TABLE new_app_schema.customers
(
    customer_id   BIGINT,
    customer_name VARCHAR(200),
    risk_score    INTEGER
);

The target table can be designed to match the application's requirements rather than blindly reproducing every object from the source namespace.

---

Step 3 — COPY the data into the target namespace

Once the files are in S3, we load them into existing_namespace:

COPY new_app_schema.customers
FROM 's3://<migration-bucket>/rc-rosters/customers/'
FORMAT AS PARQUET;

AWS reference:

COPY — Amazon Redshift SQL Reference

The resulting architecture becomes:

┌─────────────────────────────────────┐
│        existing_namespace           │
│                                     │
│  Existing tables                    │
│                                     │
│  new_app_schema                     │
│      ├── customers                  │
│      ├── rosters                    │
│      └── transactions               │
└──────────────────┬──────────────────┘
                   │
                   ▼
        existing_namespace workgroup
                 32 RPU

Now the the application workload is using the same namespace and workgroup as the existing applications.

Why this is the recommended option

The biggest advantage is that this is an actual data migration, not just data access.

After successful validation:

new_app data
      │
      │ UNLOAD
      ▼
     S3
      │
      │ COPY
      ▼
existing_namespace data

The source namespace can eventually be decommissioned.

It also gives us a controlled migration process:

Export
   ↓
Validate files
   ↓
Create target tables
   ↓
Load
   ↓
Validate row counts
   ↓
Validate application queries
   ↓
Cut over application
   ↓
Decommission source

The large-data-volume caveat

This approach is straightforward, but data volume matters.

For example:

500 GB
  │
  ▼
UNLOAD → S3 → COPY

is very different operationally from:

20 TB
  │
  ▼
UNLOAD → S3 → COPY

Large-volume migrations require planning around:

• UNLOAD duration
• COPY duration
• S3 storage during migration
• S3 request activity
• Source and target compute consumption
• Impact on existing workloads
• Migration window
• Data changing while the migration is in progress
• Validation
• Final cutover
• Whether multiple migration passes are required

The issue is not that Redshift cannot move large datasets using UNLOAD and COPY.

The issue is that large datasets turn a simple copy into a migration project.

For very large the application datasets, we should therefore assess whether the migration window, source-change rate, target workload impact, and validation requirements make this approach practical.

Where network isolation is important, Redshift supports VPC endpoints and enhanced VPC routing so COPY and UNLOAD traffic between a workgroup and S3 can remain within the VPC.

AWS reference:

Controlling database traffic with VPC endpoints

---

Option 3 — Snapshot / Table Restore

The third option is snapshot/table restore.

Redshift Serverless supports restoring a specific table from a snapshot or recovery point into a target database, schema, and new table name.

Conceptually:

new_app namespace
        │
        │ Snapshot
        ▼
   Recovery point
        │
        │ Restore table
        ▼
existing_namespace namespace

For example, we could restore a source table into the existing namespace rather than restoring an entire database.

AWS documents this capability here:

Restoring a table — Amazon Redshift

The important detail is that table restore is not the same thing as restoring the entire namespace.

AWS states that a specific table can be restored by specifying the source snapshot/recovery point, source database/schema/table, and target database/schema/table. The restored table gets the source table's column and table attributes, but dependencies such as views and permissions are not automatically applied. citeturn0search0

That makes table restore potentially useful for selected tables.

However, there are practical limitations.

For example:

• Only one table can be restored at a time.
• Table dependencies need to be considered separately.
• Views and permissions need to be handled separately.
• The restored table represents the state captured by the snapshot/recovery point.
• It does not automatically solve the application cutover problem.

AWS also supports restoring an entire snapshot to a Serverless namespace, but there is a major difference:

Restoring a snapshot to a Serverless namespace replaces the current database with the database in the snapshot.

That is obviously a very different operation from selectively adding the application tables into an already-active existing_namespace namespace. citeturn0search1

For that reason, full namespace snapshot restore is not a good fit for this consolidation scenario.

Recommendation for this option

Snapshot/table restore is a valid Redshift capability, but for our specific scenario it is not the preferred migration approach.

The target namespace already contains existing workloads and data.

For a controlled application-data migration, UNLOAD → S3 → COPY gives us more explicit control over what gets moved, how it gets loaded, and how the cutover is managed.

---

Comparing the Migration Options

Now the three options can be viewed side by side:

Option	What it does	Data physically moved?	Source namespace still needed?	Best use
Datashare	Provides live cross-namespace access	No	Yes	Validation, temporary access, workload testing
UNLOAD → S3 → COPY	Exports and loads selected data	Yes	No, after successful migration	Recommended for consolidation
Snapshot / Table Restore	Restores table data from a snapshot/recovery point	Yes	No, after successful migration	Selected table restoration

The easiest way to remember the difference:

Datashare
─────────
"Let us query the data where it already lives."


UNLOAD → S3 → COPY
──────────────────
"Move the data to the new home."


Snapshot / Table Restore
───────────────────────
"Restore selected data from a point-in-time backup."

---

Recap: The Two Sentences That Matter

If we remember nothing else from this post, remember these two sentences:

1. A workgroup and a namespace are locked into a strict 1:1 relationship — if we want a new, isolated workgroup, we need a new, isolated namespace to go with it.
2. Datashare exists precisely to undo the pain of that isolation — it lets a new namespace query another namespace's tables live, using its own compute, without copying any data.

Namespace and workgroup can only ever be exclusive. But thanks to Datashare, "exclusive" doesn't have to mean "isolated from everyone else's data forever." It just means everyone brings their own compute to the table.

And if the workload eventually needs to move into an existing namespace, we have a second path:

Validate with Datashare
          │
          ▼
If consolidation makes sense
          │
          ▼
UNLOAD → S3 → COPY
          │
          ▼
Move the data
          │
          ▼
Run on the existing workgroup

That is the important distinction:

Datashare is the bridge for accessing data across namespace boundaries. UNLOAD → S3 → COPY is the bridge for actually moving data across those boundaries.

If we remember nothing else from this post, remember these two sentences:

1. A workgroup and a namespace are locked into a strict 1:1 relationship — if we want a new, isolated workgroup, we need a new, isolated namespace to go with it.
2. Datashare exists precisely to undo the pain of that isolation — it lets a new namespace query another namespace's tables live, using its own compute, without copying any data.

Namespace and workgroup can only ever be exclusive. But thanks to Datashare, "exclusive" doesn't have to mean "isolated from everyone else's data forever." It just means everyone brings their own compute to the table.

---

References

1. Workgroups and namespaces — Amazon Redshift
2. Data sharing in Amazon Redshift Serverless
3. UNLOAD — Amazon Redshift SQL Reference
4. COPY — Amazon Redshift SQL Reference
5. Restoring a table — Amazon Redshift
6. Restoring a snapshot — Amazon Redshift
7. Snapshots and recovery points — Amazon Redshift
8. Controlling database traffic with VPC endpoints — Amazon Redshift