Usage limits

ClickHouse is built for speed and reliability. In order to maintain optimal performance, there are certain operating parameters we recommend. For example, having too many tables, databases, or parts can negatively impact performance. To prevent this, ClickHouse Cloud enforces limits across several operational dimensions.

Soft limits apply at three different scopes. The sections below start with the service-level limits, which are the ones most workloads run into first.

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

Your service’s specific warn and throw limits can be verified by querying system.server_settings. For example:

SELECT *
FROM system.server_settings
WHERE name IN ('max_table_num_to_warn', 'max_table_num_to_throw', 'max_database_num_to_warn', 'max_database_num_to_throw', 'max_view_num_to_warn', 'max_view_num_to_throw', 'max_dictionary_num_to_warn', 'max_dictionary_num_to_throw', 'max_named_collection_num_to_warn', 'max_named_collection_num_to_throw')

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.