# One Namespace, One Workgroup: Datashare Is Our Back Door

## 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:

A namespace and workgroup as a locked 1:1 pair Two boxes side by side. The left box, Namespace, lists Database, Schemas, Tables, Views, Users/Roles/Data, and Persistent storage. The right box, Workgroup, lists Compute, RPU capacity, Endpoint, and Networking configuration. A line labeled 1 to 1 connects them in the middle. NAMESPACE Database Schemas Tables Views Users / Roles / Data Persistent storage 1 : 1 WORKGROUP Compute RPU capacity Endpoint Networking configuration

Figure 1: One namespace, one workgroup — a locked 1:1 pair.

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.**

A namespace can only be paired with one workgroup at a time Namespace analytics-ns is connected by a solid line to analytics-wg, marked as already married. A second, dashed line from analytics-ns to a hypothetical fraud-wg is marked blocked, since a namespace can only have one partner. analytics-ns analytics-wg fraud-wg already married blocked one namespace, one partner

Figure 2: One namespace, one partner — analytics-ns is already paired; fraud-wg can't attach to it too.

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:

The 1:1 chain from namespace to workgroup to compute Namespace A points down to Workgroup A, which points down to its compute. A single straight line, no branching. Namespace A Workgroup A Its compute

Figure 3: The 1:1 relationship flows straight through — one namespace, one workgroup, one compute environment.

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.

One namespace cannot cleanly fan out to three workgroups A box labeled Same Namespace connects down to three workgroup boxes, WG-A at 24 RPU, WG-B at 32 RPU, and WG-C at 16 RPU, illustrating the ambiguity of one namespace serving multiple workgroups. Same Namespace WG-A 24 RPU WG-B 32 RPU WG-C 16 RPU

Figure 4: If one namespace fanned out to three workgroups, whose usage limit applies? The model stays ambiguous.

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:

A workgroup owns compute, endpoint, and network configuration Namespace points down to Workgroup. Workgroup branches into three items it owns: Compute, Endpoint, and Network configuration. Namespace Workgroup Compute Endpoint Network configuration

Figure 5: A workgroup owns its own compute, endpoint, and network configuration — separate from the namespace.

---

#### 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:

The default, predictable 1:1 shape Namespace, holding data and database, connects 1 to 1 down to Workgroup, which holds compute and endpoint. Namespace Data / Database 1 : 1 Workgroup Compute / Endpoint

Figure 6: The default, predictable shape — one namespace, one workgroup, connected 1:1.

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:

The naive attempt to fan a namespace out to two workgroups Namespace points down to two workgroups, WG-A at 24 RPU and WG-B at 32 RPU, marked not supported, since Redshift Serverless does not allow this. Namespace not supported WG-A 24 RPU WG-B 32 RPU

Figure 7: The naive fix doesn't work — a namespace can't fan out to two workgroups.

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.

The datashare pattern: producer and consumer namespace/workgroup pairs On the left, the producer: analytics-ns, holding customers and transactions data, connected up to its own analytics-wg compute. On the right, the consumer: fraud-ns, which sees the shared data but owns nothing itself, connected up to its own fraud-wg compute, which pays for and runs the JOIN. A horizontal arrow labeled Datashare, read-only, no copy, connects the producer namespace to the consumer namespace. PRODUCER CONSUMER analytics-ns owns the data customers · transactions fraud-ns sees the data, owns nothing DATASHARE (read-only, no copy) analytics-wg its own RPUs, untouched by fraud's queries fraud-wg its own RPUs runs the JOIN — pays its own compute bill

Figure 8: The datashare pattern in practice — analytics-ns/analytics-wg (producer) and fraud-ns/fraud-wg (consumer), connected read-only, no copy.

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:

What we already have: analytics-ns through analytics-wg to its tables analytics-ns points down to analytics-wg, running 24 RPU, which points down to the customers and transactions tables. analytics-ns analytics-wg 24 RPU customers transactions

Figure 9: What we already have — analytics-ns, its workgroup, and the tables it owns.

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

What we want: a new fraud-ns paired with its own fraud-wg fraud-ns points down to fraud-wg, running 32 RPU. fraud-ns fraud-wg 32 RPU

Figure 10: What we want — a brand-new fraud-ns / fraud-wg pair, fully isolated.

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:

The full producer/consumer datashare we're about to build A producer box containing analytics-ns, its workgroup analytics-wg at 24 RPU, and the shared tables public.customers and public.transactions. A Datashare arrow points down to a consumer box containing fraud-ns, its workgroup fraud-wg at 32 RPU, and its own fraud\_detection.suspicious\_activity table. PRODUCER analytics-ns analytics-wg · 24 RPU public.customers public.transactions Datashare CONSUMER fraud-ns fraud-wg · 32 RPU fraud\_detection.suspicious\_activity \+ shared: customers, transactions

Figure 11: What we're about to build — a producer/consumer datashare between analytics-ns and fraud-ns.

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:

```sql
CREATE DATASHARE fraud_share;
```

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

In our example, that's just two tables:

```sql
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.

Only two tables in analytics-ns are actually shared analytics-ns branches into five objects. public.customers and public.transactions are marked shared. internal.audit\_log, staging.raw\_events, and admin.etl\_control are marked not shared. analytics-ns SHARED public.customers public.transactions NOT SHARED internal.audit\_log staging.raw\_events admin.etl\_control

Figure 12: The datashare only exposes what's explicitly added — everything else in analytics-ns stays private.

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`:

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

Think of this as the guest-list check.

Granting usage on the datashare to the consumer namespace analytics-ns points down to fraud\_share, which points down to fraud-ns, labeled fraud-ns is allowed in. analytics-ns fraud\_share "fraud-ns is allowed in" fraud-ns

Figure 13: Granting usage on the datashare is the guest-list check — only fraud-ns gets in.

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:

```sql
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:

fraud-ns after accepting the datashare fraud-ns branches into its own native table, suspicious\_activity, and a shared group giving access to public.customers and public.transactions via the datashare. fraud-ns OWN TABLE suspicious\_activity SHARED VIA DATASHARE public.customers public.transactions

Figure 14: From fraud-ns, the native suspicious\_activity table sits alongside the shared analytics data.

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:

```text
fraud_detection.suspicious_activity
```

It contains:

```text
transaction_id
customer_id
flag_reason
```

Meanwhile, the producer owns:

```text
public.customers
```

with:

```text
customer_id
customer_name
risk_score
```

Our fraud workload can now combine the two:

```sql
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:

```text
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:

Data ownership and compute ownership, joined only by the datashare On the left, data ownership: analytics-ns down to the customers and transactions tables. On the right, compute ownership: fraud-ns down to fraud-wg at 32 RPU. Both converge through the datashare into a single query and JOIN. DATA OWNERSHIP COMPUTE OWNERSHIP analytics-ns customers table transactions table fraud-ns fraud-wg 32 RPU Datashare Query + JOIN

Figure 15: Data ownership stays with analytics-ns; compute ownership stays with fraud-wg — Datashare is the only bridge.

**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.

---

Originally published at https://senthilnayagan.com/blog/one-namespace-one-workgroup-datashare-is-your-back-door/