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.

---

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.