This message was deleted.

Hi Peter, I have been involved with clusters that fit the following scenarios: • Full multi-tenant -- use TenantID fields in every datasource ... and the datasource is then usually range partitioned on TenantID first) • Full single-tenant -- schemas that have single tenant datasources using a prefix or suffix in the datasource name to identify the tenant. • Hybrid approach -- using a combination of both of the above, e.g. they have single tenant and multi-tenant versions of the datasources, depending on data volume and query traffic per tenant • Hybrid approach at the cluster level -- multiple clusters, some multi-tenant and some single-tenant, if the cluster does not provide enough workload isolation between tenants Thanks. John

Thanks, John! I know there are pros and cons to each approach. Based on your experience, which approach would you recommend. Full multi-tenant changes our data loading and querying since the predicate must always include the tenantID. Full single-tenant - we currently have this approach now for the RDBMS. I just need to figure how to deploy Druid in a k8s and and access it via a separate data source. Both hybrid approach provides more flexibility but comes at a higher maintenance, development, and support cost. Regards,

Full single tenant I have seen cause problems ... if you end up with hundreds of tenants then you also end up with hundreds of datasources, and each one has segment fragmentation issues and compaction needs, etc ... so becomes a lot more work. So my preference is full multi-tenant if you don't have significant resource isolation issues. Yes, every query includes the filter on TenantID, but that also means every datasource can be range partitioned by tenantID first, makes for good query pruning. My second choice would be Hybrid, meaning you only split out a tenant into its own schema if it is causing problems for the other tenants in the main schema. For this I would suggest still leave the tenantID field in, because over time you could move tenants around between the (few) schemas, ending up with cleverly balanced set of just a few multi-tenant schemas, giving you the benefit of resource isolation without most of the maintenance overhead.

Thank you very much!

Of course you have to code the dynamic substitution (or adding prefix/suffix) of datasource names in all of the queries that are formed, but once you have this set up you can parameterize it for fairly low maintenance.