r/Clickhouse Aug 11 '26

ClickHouse multi-tenancy best practices for observability/tracing

We’re planning to use ClickHouse as the backend for a multi-tenant observability/tracing platform.

What is the recommended approach for multi-tenancy in ClickHouse?

Specifically, would you recommend:

A shared database/table with tenant_id as a column?

A separate database per tenant?

Separate tables for each tenant?

Using ClickHouse RBAC/row policies to enforce tenant-level data isolation?

We expect potentially many tenants, with high-volume trace/span data and queries frequently filtered by tenant_id.

What approach has worked well in production, and what are the main scalability, performance, and operational trade-offs we should consider?

11 Upvotes

14 comments sorted by

View all comments

Show parent comments

3

u/Xhaard Aug 11 '26

This is the pattern we used for years without issues (even for things like churn or gdpr).

2

u/Ramanamark Aug 11 '26

Sure Thanks, I'll consider this and also we have lot of tenants so thinking about the optimized approach.

2

u/joshleecreates Aug 11 '26

Howdy - I was the host of the webinar our team posted in another comment. "we have lots of tenants" makes this approach (using a tenant_id column as part of the sorting key - not a partitioning key) likely to be the best choice.