Warehouses

[Edit this page](https://github.com/ClickHouse/clickhouse-docs/blob/main/docs/cloud/features/05_infrastructure/warehouses.md)

Scale plan feature

Compute-compute separation is available in the Scale and Enterprise plans. To upgrade, visit the plans page in the cloud console.

## What is compute-compute separation?[​](#what-is-compute-compute-separation "Direct link to What is compute-compute separation?")

Before discussing what compute-compute separation is, it's helpful to understand what a **service** is in ClickHouse Cloud.

Each ClickHouse Cloud service includes:

- ClickHouse compute nodes (referred to as **replicas**) with dedicated CPU and memory clusters
- An endpoint (or multiple endpoints created via ClickHouse Cloud UI console) to connect to the service (for example, `https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443`) for local and third party app connections
- An object storage folder where the service stores all the data and part of the metadata:

  

*Fig. 1 - Single service in ClickHouse Cloud*

Rather than having a single service, you can create multiple services that have access to the same shared storage, which allows you to dedicate resources to specific workloads without having to duplicate data.
This concept is called **compute-compute separation**.

Compute-compute separation means that each service has its own set of replicas and an endpoint, but it uses the same object storage folder and accesses the same tables, views, etc.
This means you can choose the right size compute for your workload. Some of your workloads may be satisfied with only one small-size replica, and others may require full high-availability (HA) and hundreds of gigs of memory on multiple replicas.

Compute-compute separation also allows you to separate read operations from write operations so they don't interfere with each other:

  

*Fig. 2 - Compute separation in ClickHouse Cloud*

## What is a warehouse?[​](#what-is-a-warehouse "Direct link to What is a warehouse?")

In ClickHouse Cloud, a *warehouse* is a set of **services** that share the same data.
Each warehouse has a primary service (the service created first) and one or more secondary services.
For example, in the screenshot below, you can see a warehouse "DWH Prod" consisting of two services:

- Primary service `DWH Prod`
- Secondary service `DWH Prod Subservice`

  

*Fig. 3 - Warehouse example*

All services in a warehouse share the same:

- Region (for example, us-east1)
- Cloud service provider (AWS, GCP or Azure)
- ClickHouse database version
- ClickHouse Keeper (for managing replicas)

## Access controls[​](#access-controls "Direct link to Access controls")

### Database credentials[​](#database-credentials "Direct link to Database credentials")

Because all services in a warehouse share the same set of tables, they also share access controls across services.
This means that all database users that are created in Service 1 will also be able to use Service 2 with the same permissions (grants for tables, views, etc), and vice versa.
A different endpoint is used for each service, but the same username and password is used across all services. In other words, **users are shared across services that work with the same storage** as shown in the figure below:

  

*Fig. 4 - User Alice was created in Service 1, but she can use the same credentials to access all services that share same data*

### Network access control[​](#network-access-control "Direct link to Network access control")

To restrict access to specific services by other applications or ad-hoc users, you can apply network restrictions.
To do so, navigate to **Settings** in the service tab of the particular service you wish to restrict access to in ClickHouse Cloud console).

IP filtering settings can be applied to each service separately, which means you can control which application can access which service.
This allows you to restrict users from using specific services.

In the example below, Alice is restricted from accessing service 2 in the warehouse:

  

*Fig. 5 - Alice is restricted from accessing service 2 because of network access control settings*

ClickHouse roles and grants can also be applied to control access to the data when users are connecting as an individual rather than the *default* user.

### Read vs read-write services[​](#read-vs-read-write "Direct link to Read vs read-write services")

Services can be one of:

- **read-write**
  - Can both read and write data to ClickHouse
  - Performs background merge operations (e.g., merging parts after data inserts), which consume CPU and memory
  - Can export data externally
- **read-only**
  - Can only read data; it cannot write or modify data in ClickHouse
  - Does not perform background merge operations, so its resources are fully dedicated to read queries
  - Can still export data externally (e.g., via table functions), but cannot change data inside ClickHouse
  - Idles without delay, unlike read-write services which may be kept awake by background merges.

Sometimes you want to isolate critical read workloads from write/merge overhead by making a service read only.
You can do so for the second service and any additional services you create, however the first service will always be read-write, as shown in the figure below:

  

*Fig. 6 - Read-write and Read-only services in a warehouse*

Note

1. Read-only services currently support user management operations (CREATE, DROP, etc).
2. [Refreshable materialized views](/docs/materialized-view/refreshable-materialized-view) run **only** on read-write (RW) services in a warehouse.

## Scaling[​](#scaling "Direct link to Scaling")

Each service in a warehouse can be adjusted to your workload in terms of:

- Number of nodes (replicas). The primary service (the service that was created first in the warehouse) should have 2 or more nodes. Each secondary service can have 1 or more nodes.
- Size of nodes (replicas)
- If the service should scale automatically (horizontally and vertically)
- If the service should be idled on inactivity

For more information, see the ["Autoscaling"](/docs/manage/scaling) page.

## Changes in `clusterAllReplicas` behavior[​](#changes-in-behavior "Direct link to changes-in-behavior")

Once a warehouse has multiple services, the behavior of `clusterAllReplicas()` changes.
Using the `default` cluster name will only target replicas within the current service, not all services in the warehouse.

For example, if you call `clusterAllReplicas(default, system, processes)` from service 1, only processes running on service 1 are returned.
To query across all services in the warehouse, use the `all_groups.default` cluster name instead:

```
SELECT * FROM clusterAllReplicas('all_groups.default', system, processes)
```

Note

Secondary single-node services can scale vertically, while primary single-node services cannot.

## Limitations[​](#limitations "Direct link to Limitations")

### Workload isolation limitations[​](#workload-isolation-limitations "Direct link to Workload isolation limitations")

Some workloads can't be isolated to specific services; there are edge cases where one workload in one service will affect another service in the warehouse. These include: