Scaling

Every Nistor role is a Cloud Run service or job, built from the same nistor-runtime image (nistor serve <role>). Cloud Run adds instances as requests arrive, between each service's minimum and maximum. The database does not scale by itself: it is one Cloud SQL instance, sized by db_tier.

What to scale#

• More users or API calls: the backend. Raise its maximum instances in your copy of the root, or its backend_max_concurrency. Keep backend_min_instances at 1 or more, so that scheduled and service-to-service calls meet no cold start.
• Bigger graphs, slower compiles: the compiler. Raise compiler_memory and compiler_cpu together (see Sizing). More instances do not make one compile faster.
• More data-quality checks running at once: the runner (data-quality executor) and its maximum instances.
• Database connections: every instance opens up to db_pool_size + db_max_overflow connections per worker. Before you raise maximum instances, check that the total stays under max_connections for your db_tier. Add a read replica (enable_read_replica) for read-heavy loads.

Quotas#

A new Google Cloud project has default Cloud Run quotas per region, and the reference root's defaults can exceed them. The figures below are the quota defaults the root's input descriptions assume; check your project's current values.

• CPU. Each compiler instance takes 8 vCPU, and the default CPU quota is 20 vCPU per region. Without a raised quota, set compiler_max_instances = 2 (16 vCPU).
• Memory. The default memory quota is 40 GiB per region, counted over running instances. During a deploy, each role's old and new revisions run side by side. Without a raised quota, set a smaller backend_memory (for example 4Gi) in dev and test.

Request a quota increase in the Google Cloud console (IAM & Admin → Quotas) before you raise maximum instances in prod.