The scope of the data object limits (databases, tables, columns, partitions, and parts) depends on how you run your services.
If you run standalone services, these limits apply per service.
As soon as services share data in a warehouse, the same limits instead apply once to the warehouse’s shared catalog.
The numbers don’t change — only the level they are measured at does.
Service limits
The limits below apply to a standalone service (and, for data object counts, to that service’s storage). If the service belongs to a warehouse, the data object limits (databases, tables, columns, partitions, and parts) instead apply to the warehouse’s shared catalog, as described in Warehouse limits below — the values are unchanged, but they are measured across the whole warehouse rather than the single service. The remaining limits, such as query concurrency and batch ingest, stay per-service (or per-replica) in both cases.
The values above are default guardrails. The limit enforced for a specific service may be higher than the value shown here, as larger services are configured with more headroom. The actual limit that applies to your service is included in the warning you receive as you approach it. For services already exceeding these limits, the table and database limits are set at the service’s current count plus 25%.
For Single Replica Services, the maximum number of databases is restricted to
100, and the maximum number of tables is restricted to 500. In addition, storage
for Basic Tier Services is limited to 1 TB. The view, dictionary, and named
collection limits above are a single value that applies to all services,
including Single Replica Services.
system.server_settings. For example:
Warehouse limits
A warehouse is a set of services that share the same data. Warehouse limits apply to that shared group as a whole — not to each service separately or across the organization.
The replica limit is the combined replica count across all services in the warehouse.
Because every service in a warehouse shares a single ClickHouse Keeper, this limit exists to protect Keeper stability. The default of 50 is soft and depends on your data and workload; the ceiling is higher on ClickHouse 26.6+, and we plan to raise it further in the future.
Contact support to raise it; for more detail on warehouse scaling, see warehouses.
There is no separate cap on the number of services in a warehouse — it is bounded only by the combined replica limit above.
Because services in a warehouse share one catalog (the same tables, databases, views, and so on), the service-level data object limits above are counted once per warehouse rather than multiplied per service. Separate warehouses are isolated from each other, so each warehouse counts its own tables and databases toward these limits.
Organization limits
These limits apply across an entire ClickHouse Cloud organization — that is, across all of its warehouses and services combined.
The services per organization limit counts every service across all warehouses in the organization. This is a historical guardrail rather than a hard cap; contact support and they can typically raise it after a quick review.