How far does one-Schedule-per-tenant scale?

Community Support
1

We have a multi-tenant backend with a set of recurring jobs, and today each tenant gets its own Schedule for each job type. So the Schedule count grows with the tenant count:

schedules = jobTypes × tenants

With 9 job types that’s 18,000 Schedules at 2,000 tenants, and 90,000 at 10,000 tenants.

The cron expression is per job type, not per tenant — every tenant shares the same one — so all the Schedules of a given type fire at the same instant.

Is this a shape Temporal is meant to serve, and how far does it scale? Specifically:

  1. Is there a practical ceiling on the number of Schedules in a namespace, and on how many can fire simultaneously?
  2. At what point should we stop adding Schedules per tenant and switch to a different pattern?
  3. If there’s a recommended alternative for this (one Schedule per job type that looks tenants up, long-running workflows with timers, something else), which would you point us at?

We’re on self-hosted. Happy to share what we’ve measured if that’s useful, but we’d rather hear the intended design first.

2

Temporal can scale well beyond 100k schedules. Even if a Temporal cluster processes its firing quickly, do you have enough compute to react to them as fast?