RadiatorDB sizing

RadiatorDB sizing

RadiatorDB operates with Radiator, but its resource requirements are driven by the stored data and database operations. Reads, writes, retained revisions, and replication place different demands on each RadiatorDB node. This guide focuses on RadiatorDB resources. See Radiator sizing for the Radiator processes in the same deployment.

CPU and memory sizing

The following values apply to a typical deployment with two Radiators and two RadiatorDB nodes in a full mesh. The database contains one million subscriber profiles. TPS is the aggregate transaction rate across both Radiators. CPU and memory values are for each RadiatorDB node.

• Reference CPU performance: 4,750 sysbench cpu events per second for each CPU. CPU requirements scale inversely with the per-CPU benchmark result.

Read-only processing retrieves a subscriber profile and writes the authentication log to local disk. The latest-state session workload performs the same read and updates one session document for every authentication. It uses asynchronous commit and retains no revision history for session documents. Memory is primarily determined by the live data, indexes, and active working set rather than TPS. The 4 GiB value includes the one-million-profile data set, latest-state sessions, normal caching, and the observed increase during node recovery. Larger documents, more indexes, and retained revisions require more memory.

For a PostgreSQL and Linux configuration based on the 10,000 TPS measurements, see RadiatorDB PostgreSQL 10k TPS example.

Capacity during node loss

When one RadiatorDB node is unavailable, the remaining node processes the entire deployment workload. The following CPU values preserve the same target TPS during this condition.

Recovery consumes CPU, memory, storage bandwidth, and network bandwidth while the node catches up with current writes.

Storage sizing

Every RadiatorDB node stores the complete data set. Storage includes live documents, indexes, metadata, retained revisions, tombstones, and replication backlogs. Each node also needs working space for maintenance and backups. SSD-backed storage is preferred. Storage latency affects database reads, writes, replication catch-up, backup, and restore performance.

required storage =
    live documents and indexes
    + retained revisions
    + tombstones
    + peak replication backlog
    + backup space
    + 30% free space

These examples show how the data model affects storage on each node:

Latest-state sessions keep one current document for each session. Repeated updates do not create revision rows. Write rate affects CPU and replication traffic, while retained storage follows the number of active sessions. Subscriber profile changes create retained revisions.

For a subscriber base with one million profile changes per month, a configured 30-day retention period holds approximately one million revisions. The changes add approximately 0.9 GiB per node before free space, replication backlogs, and backup space. By default, RadiatorDB retains all revisions. Configure revision cleanup limits to limit storage growth.

The live subscriber count determines the base storage. Monthly profile changes and retention determine the revision storage.

Bulk operations

Bulk restore, profile updates, and backup add work outside the steady transaction rate. For one million subscriber profiles:

The backup contains one million current subscriber profiles and one million profile revisions. Backup and restore rates also depend on storage and network throughput.

Replication sizing

RadiatorDB replication is a full mesh. Every RadiatorDB node connects to every other node. A write made on one node is sent directly to all other nodes.

A six-node cluster has 15 bidirectional peer links, or 30 directed replication connections:

Each replica increases the write, storage, network, and replication-worker load across the cluster. Nodes that receive writes retain a replication backlog for an unavailable replica. Recovery processes that backlog alongside live traffic. At high write rates, replication and recovery demand can outweigh the availability benefit of additional replicas.

Central writes and branch replicas

When authentication and authorization reads are the priority, one RadiatorDB node can receive profile writes and any reads that must immediately observe those writes. Reading from the node that accepted a write provides read-after-write consistency. Branch nodes can serve local reads and session writes. This arrangement does not reduce total replication or storage: every change is replicated to every node.

During normal operation, all five RadiatorDB nodes have direct full-mesh replication connections. The outward arrows show representative subscriber profile updates from the HQ node to every branch. Branch-to-branch links are omitted. Each branch Radiator uses its local RadiatorDB node first and can use the HQ node as a fallback while the WAN is available. If a branch loses its WAN connection, its Radiator continues using the local RadiatorDB node. Local changes and central changes for that branch synchronize after connectivity returns.

Configuration

See RadiatorDB multi-node setup for cluster and replication-worker configuration. The RadiatorDB backend configuration covers node addresses, connection pools, priorities, synchronous commit, and revision retention. RadiatorDB backup describes backup and restore operations.