Capacity Planning

This guide helps you size a Mockarty installation before it goes live: how much
CPU and memory each component needs, how many PostgreSQL connections to
provision, and which settings to change as you grow. The numbers below are the
product’s real defaults, not estimates.

For how the components fit together, see Scaling Architecture.

Starting sizes

A desktop or evaluation install needs only the admin node: it can keep its data
in a local SQLite file and its cache in memory.

Helm chart defaults

The Helm chart ships requests and limits that let every pod start on a small
cluster. Treat them as a floor: for production, set the admin node’s CPU and
memory to at least the recommended size above.

Change them in your values file, for example:

admin:
  resources:
    requests: { cpu: "1", memory: 2Gi }
    limits: { cpu: "4", memory: 4Gi }

PostgreSQL connections

Running out of database connections is the most common capacity problem in a
multi-node installation: requests start failing even though CPU and memory are
fine. Plan the connection count before you scale.

Each admin node keeps two connection pools and a few dedicated connections for
live updates:

“CPU” is the CPU limit of the admin container (or of the machine, when there is
no limit). So one admin node uses at most:

per admin node = DB_MAX_OPEN_CONNS + BOOTSTRAP_DB_MAX_OPEN_CONNS + 10

Count every pod that can exist at the same time — the autoscaling maximum plus
the extra pod a rolling update starts — and keep the total at or below 80 % of
PostgreSQL’s max_connections. The rest is for backups, migrations and your own
sessions:

total = (admin pods + surge) × per admin node + (resolver pods + surge) × 3

How the chart’s own profiles add up:

The chart raises max_connections of its bundled PostgreSQL for exactly this
reason: PostgreSQL’s own default of 100 is too small even for one admin node
during a rolling update. With an external PostgreSQL, apply the formula to your
shape and either raise max_connections or lower the pools:

admin:
  env:
    DB_MAX_OPEN_CONNS: "15"
    BOOTSTRAP_DB_MAX_OPEN_CONNS: "16"
postgresql:
  primary:
    extendedConfiguration: |
      max_connections = 300

Every PostgreSQL connection costs server memory, so raise PostgreSQL’s memory
together with max_connections. With many resolvers, a connection pooler in
front of PostgreSQL keeps the count low.

SQLite (desktop and single binary)

A node that stores its data in SQLite opens its main pool at 2 connections per
CPU (between 4 and 32, SQLITE_MAX_OPEN_CONNS overrides it) and a service pool
of 1 per CPU (between 4 and 8). Reads run in parallel; writes take turns. SQLite
suits one person or a small team on one machine — move to PostgreSQL before
several people write at the same time.

Redis

Each admin node opens up to 10 Redis connections per CPU, never fewer than 20
(CACHE_REDIS_POOL_SIZE overrides it), and keeps at least 4 of them warm
(CACHE_REDIS_MIN_IDLE_CONNS). If your Redis limits clients, keep
admin pods × pool size below its maxclients.

In-memory cache

Without Redis, each admin node caches in its own memory, up to 200 MB by default
(REPO_INMEMORY_MAX_SIZE_MB). Count it in the admin node’s memory limit.

Disk

Database disk grows with the history you keep — request logs, test run results
and the audit log — not with the number of mocks or users. Set the cleanup
policies in the administration panel to match the retention you need, then plan
disk as daily volume × retention days plus about 30 % headroom. Large report
files and attachments go to the file or object storage, which you size
separately. Scaling Architecture has worked
examples for small, medium and large teams.

When to scale