Hardware Sizing Guide

Deployment Architecture

GraphnAI runs as two components:

The server stores the graph, runs the analysis and serves the UI. The bridge connects out to the server, so it needs no inbound firewall rules.

Server Container Requirements

The server and ArangoDB share one Docker host. ArangoDB uses most of the RAM and storage during a sync.

Understanding the estimates

• Identities are the users, groups, computers, service accounts, service principals, OUs, containers and domain objects synced from Active Directory and Entra ID.
• Edges are the memberships, ACL permissions, containment and other links in the identity graph. Complex ACLs, with many delegated permissions or fine-grained security descriptors, mean more of them. Expect 10 to 20 per identity.
• RAM matters most. During a sync, ArangoDB's write-ahead log, RocksDB block cache and indexes compete for memory. Analytics also holds each domain's peer groups in memory. Too little RAM slows a sync down without crashing it (see Resource Sizing & Tuning below), and a comfortable margin keeps syncs fast. At the top of the Medium tier, the largest single domains push against 16 GB. Use 24 GB for a domain with 90,000 identities or more.
• Storage should be NVMe or fast SSD, never a spinning disk or a slow network volume. ArangoDB stores data with RocksDB, and the sync throttle paces RocksDB's background compaction by the disk's own back-pressure signals. On a fast disk the throttle runs wider, and on a slow one it brakes harder. Allow about twice the live data size for compaction.

Resource usage pattern

GraphnAI's workload comes in bursts:

• Idle and query time (most of the time): Light topology queries, dashboard reads and cached analytics. Little resource use.
• Sync bursts (periodic): Heavy writes during scheduled syncs, while GraphnAI builds graph edges, evaluates criticality and runs analytics. RAM and CPU peak here.

Size for the sync burst. Queries run comfortably even on the Small tier.

Identity Bridge Requirements

Each bridge is lightweight. CPU matters most, because parsing Active Directory security descriptors is CPU-bound.

Number of Bridges

Deploy one bridge per network segment that has Active Directory domain controllers:

You manage bridges from the GraphnAI UI. See Bridge Configuration for deployment steps.

Cloud / SaaS Considerations

In the cloud, the bursty workload makes scaling on demand worthwhile:

• Scale up before a sync. If syncs run on a schedule, for example nightly, give the container more memory before the sync window and scale it back afterward.
• Plan ArangoDB memory ahead. RocksDB's block cache grows as data is read. Adding memory before the sync starts works better than adding it mid-sync.
• Keep the server's data directory. The server keeps its root key and its certificate authority there. Everything else lives in ArangoDB. Put the data directory on persistent storage and back it up with the database. A server that loses its root key creates a new one. It then can't read the settings it stored encrypted, such as sign-in providers and bridge credentials.

Recommendations by Deployment Type

Small / Proof of Concept

A single VM with 8 GB of RAM and 2 cores handles up to 10,000 identities comfortably. It suits evaluations, single-domain environments and small organizations.

Medium / Multi-Domain

16 GB of RAM and 4 cores support most mid-size organizations. With several Active Directory domains, plan one bridge per network segment. Syncs finish in a few minutes.

Large / Enterprise

Use 32 to 64 GB of RAM. At this scale a sync produces millions of edges, and its duration depends on ArangoDB's write throughput. Adaptive throttling keeps the database from overloading, and enough RAM lets syncs finish without intervention.

Multi-Forest / Global

For 500,000 identities or more across several forests, contact your GraphnAI representative to plan the architecture. Cross-forest trusts, sync scheduling and network topology all shape the best layout.

Resource Sizing & Tuning

The sync pipeline sizes its concurrency and batch sizes from the resources granted to the container. It ignores the Docker host's totals. It reads the cgroup CPU quota (docker --cpus=N) and memory limit, so a container with a quota doesn't oversubscribe the host.

Two behaviors follow:

• It scales up. Give the server container more cores, and edge building and analytics use them. The writer count is the core count minus some headroom, with no fixed cap. Past about 16 cores the gains taper, because the database's write path becomes the bottleneck. For one large domain, cores beyond 16 help less than RAM and fast storage do.
• It slows down instead of crashing. On a memory-tight host, the throttle paces edge building against the database's compaction back-pressure. A deployment that grows its identity count without adding RAM gets slower and keeps running. The server process also sets a Go soft memory limit from its container's memory limit, minus a small reserve. Its largest working sets, the full-sync edge reconcile and the analytics snapshot, then pace garbage collection to stay under that limit instead of being killed.

In testing, a re-sync of a 911,000-identity domain on a Medium host, with the server process limited to 5 GiB, peaked near 97% of that limit and finished. For much larger graphs, use 24 GB of RAM.

Per-tier notes

Tier minimums become hard requirements only after testing on shared reference hardware. The notes above are sizing guidance.

Tuning overrides (advanced)

Sizing is automatic. If you've measured a reason to change a setting, contact your GraphnAI representative before you override it.

Support

Contact your GraphnAI account representative for sizing advice for your environment.