> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/deployment/sizing.md). # Sizing What actually drives load in an OpenIAM deployment, what to measure before committing to node sizes, and how to read the published reference figures — including which of them are guarantees and which ## What this is, and when you need it Sizing an OpenIAM deployment is a two-part exercise: work out what the design will ask the platform to do, then translate that into machines. This page covers the first part properly, gives you the arithmetic that the shipped material actually supports, and is explicit about which published figures are load-bearing and which are a starting point. You need it when a budget number has to be produced, which is usually earlier than anyone would like and on less evidence than anyone would like. The honest framing to take into that conversation is that node sizing is a hypothesis you validate, not a calculation you complete. ## The decision | Question | What it decides | How to answer it | | ------------------------ | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | How many nodes | Availability, and whether tiers are separated | [Choosing a topology](/solution-architecture/deployment/choosing-a-topology.md). This is not a sizing question | | How much memory per node | Whether the services fit at all | Bottom-up from the shipped allocations, below. This is calculable | | How much CPU per node | Whether bulk work completes in its window | Measured. Start from the reference figures and validate against a real synchronization | | How much disk | Search tier and database growth | Driven by object count and audit retention, not by user count | | What database tier | Whether the connection count fits | Calculable from replica counts, below. This is the one people get wrong | ## What drives load Five things, in rough order of how often they decide a sizing. **Bulk identity work.** Full synchronizations from authoritative sources, reconciliation against large managed systems, and bulk provisioning runs. These are the heaviest workloads OpenIAM runs, they are bursty, and they are what justifies separating the infrastructure tier. Their cost tracks the size of the *source or target*, not the size of your OpenIAM population — reconciling a directory of two hundred thousand accounts is expensive even if you manage twenty thousand people. **Certification campaigns.** A campaign that covers every user and every entitlement materialises a very large set of review items in one operation. Campaign scope, not population, is the driver: a quarterly campaign across everything is a different platform from an annual campaign across privileged access. **Interactive sign-in volume.** Peak sign-ins per hour, not per day. This is what sizes the identity provider and the console tier, and it is the argument for separating them in the largest topologies. **Object count and entitlement graph size.** Users, groups, roles, resources, organizations, managed systems and the memberships between them. This sizes the search tier and the graph store, and it grows with the *access model* — a design with fine-grained roles has a much larger graph than one with coarse roles over the same population. **Audit volume and retention.** Every audited action becomes a document in the search tier. This grows with activity and with how long you keep it, and it is the part of the search tier that has no database source, so it cannot be trimmed by rebuilding. Audit retention is a sizing decision as much as a compliance one. Note what is not on that list: the number of named users, on its own. It matters, but only through the four items above. A design conversation that starts and ends with "how many users?" has not sized anything. ## What to measure before committing Four numbers, and none of them is the user count. 1. **The largest full synchronization**, in records, and the window it must complete in. 2. **The largest reconciliation target**, in accounts, and its frequency. 3. **Peak sign-ins in the busiest hour**, and whether the design puts OpenIAM on the sign-in path for every application or only some. 4. **Audit retention**, in months, and whether audit is exported continuously to an external platform or kept in OpenIAM. If the customer cannot answer these, size for the topology rather than for the load, build in an environment you can measure, and revisit. That is a better position than a precise-looking number derived from nothing. ## The arithmetic that is actually calculable Two parts of sizing are not guesswork, and both are worth doing before anyone quotes a machine type. ### Memory, from the shipped allocations Both distributions declare what each component is allowed. On the packaged Linux distribution each service's unit carries a heap ceiling; on the container distribution each workload carries a memory limit. Adding them up gives a defensible floor. | Tier | Approximate total, one instance of everything | What it tells you | | --------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | Backend services | About 13 GB of heap | The floor for a service node, before JVM overhead and the operating system | | Consoles, identity provider and report viewer | About 12 GB of heap | The floor for a console node. This is why a separated console tier is specified smaller than a service tier | | Both together | About 25 GB of heap | Why the single-instance shape is specified with well over 30 GB — the infrastructure components have to fit alongside it | Two things to take from this. First, **a console node and a service node should not be the same size**; if a proposed design has them equal, one of the two numbers has not been thought about. Second, the heap ceilings are ceilings — a service that never does bulk work will not approach its limit — so this is a floor for provisioning, not a prediction of usage. On the container distribution the equivalent limits are per replica, and the shipped values set three replicas of every service and every console. Multiply accordingly: a three-worker cluster is provisioning three copies of the whole application tier plus the in-cluster infrastructure. ### Database connections, from the replica count This is the calculation most often missed, and it is the one that causes a managed database to be provisioned too small. **OpenIAM's deployment tooling configures the database's connection limit as thirty-five connections per replica of the ESB, the workflow service and the authorization service** — and, when the database itself is self-managed, per replica of the Groovy service as well. A three-replica deployment therefore asks for several hundred connections before any unusual activity. Check that number against the connection cap of whatever database tier is proposed. The consequence is concrete: on Google Cloud, none of the standard PostgreSQL machine tiers provides enough concurrent connections for an OpenIAM deployment, and a custom tier is required. Other platforms have the same issue at smaller tiers without documenting it as clearly. **The corollary is worth stating in a design review: adding nodes for availability increases the database's connection requirement.** Availability and database sizing are not independent decisions. ## The reference figures, and what they are worth Two sets of published numbers exist, and they carry different weight. Keep the distinction when either of them reaches a proposal. ### The deployment tooling's stated minimums The shipped deployment material states a minimum for a Kubernetes deployment: eight CPUs and 32 GB of memory with 80 GB of disk for a non-production configuration, and eight CPUs, 40 GB and 200 GB of disk for production. The cluster modules separately document a minimum worker machine type on AWS and on Google Cloud, both of which work out at roughly four virtual CPUs and sixteen gigabytes per worker. These are floors — the point below which the deployment is not expected to come up. They are not capacity guidance, and a production estate should not be sized at them. ### The per-node reference figures OpenIAM's deployment architecture material publishes indicative per-node figures for each of the nine topologies: a single instance at eight CPUs and 36 GB, HA nodes in the eight CPU and 32 to 36 GB range, infrastructure cluster nodes at six CPUs and 24 GB, separated console nodes at four CPUs and 16 GB, connector hosts at two to four CPUs and 8 to 16 GB, and Kubernetes workers at eight cores and 64 GB. **Read these as reference starting points for provisioning, not as a measurement of a particular workload.** They give the shape of a first proposal per topology, and they hold up where they can be cross-checked: a 16 GB console node sits sensibly above the roughly 12 GB of console heap the shipped units allocate, and a 32 GB service node sits sensibly above roughly 13 GB of service heap. Validate them against your own population and batch profile before committing to a production order. The drivers named earlier on this page — the batch profile, the scope of certification campaigns and the number of connectors — move these figures considerably more than headcount does, which is why two estates of the same size can land in different rows. Keep the two kinds of number apart as you work: the heap sums for a tier and the connection arithmetic for a replica count are calculable exactly and should be, while the per-node figures around them are indicative until a measured run replaces them. ## What we recommend **Size the topology first and the machines second.** Node count comes from the availability target and the batch profile. Node size comes from this page. Conflating them produces designs that are large and still not available. **Do the two calculable parts properly, because they are free.** Sum the shipped allocations for the tier you are sizing; compute the connection requirement from the replica count and check it against the database tier. Both take minutes and both catch real errors. **Build a measurable non-production environment early and run the real synchronization through it.** The largest full synchronization is the single most informative test you can run, and it is available long before go-live. One measured run is worth more than any reference table. **Size the search tier for audit, separately from everything else.** It is the component whose growth is least related to population and most related to retention policy, and it is the one whose contents cannot be wholly rebuilt. **Revisit sizing after the first quarter in production.** Bulk work grows as more managed systems are onboarded, and the batch profile at go-live is rarely the batch profile a year later. The circumstance that changes this advice is a deployment where the reference figures are being used to close a commercial position rather than to build something. There, say plainly which numbers are floors, which are references, and what has to be measured — an architect who presents an unqualified capacity number they cannot support owns the consequence. ## What OpenIAM does not do here * **There is no published sizing calculator or capacity model.** The reference figures are per-topology indications, not the output of a model you can re-run with your own inputs. * **There is no autoscaling in the shipped deployment material.** Node count and replica count are set at deployment time on every substrate. * **The shipped allocations are limits, not measurements.** They tell you what a component may use, not what it will use at your load. * **Nothing in the product measures whether your sizing is adequate.** The optional monitoring stack reports resource use; interpreting it against a target is yours. * **Sizing figures are not per-user.** No published figure expresses capacity as users per node, and any design that derives one has invented it. ## Related * [Choosing a topology](/solution-architecture/deployment/choosing-a-topology.md) — the node-count decision that comes before this one. * [Platform support matrix](/solution-architecture/deployment/platform-support-matrix.md) — the database tiers the connection arithmetic constrains. * [Where load lands](/solution-architecture/deployment/where-load-lands.md) — which component carries which workload, and which of them adding nodes will not help. * [Availability and recovery](/solution-architecture/deployment/availability-and-recovery.md) — audit retention as a recovery decision as well as a sizing one. * *Audit export to a SIEM* in the Administration Guide — what is audited, and how to move it off the platform. * The [Installation Guide](/installation/installation.md) — tuning heap, connection pools and the search tier once the deployment exists. *Applies to OpenIAM 2026.8.1. Last reviewed 13 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/deployment/sizing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.