How higher core counts expose the limitations of process-per-core database scaling

Modern server CPUs are entering territory that would have seemed extraordinary just a few years ago. AMD’s 5th Gen EPYC processors, formerly codenamed Turin, already scale to 192 cores per socket, while the next-generation EPYC 9006 processors, codenamed Venice, support up to 256 cores and 512 threads per socket. Servers are becoming both faster and denser, packing more compute into the same physical footprint and enabling software to process more work in parallel.

But there’s a catch: software doesn’t automatically know what to do with all those additional cores. A 96-core server doesn't make a single-threaded database meaningfully faster simply by adding cores. In configurations where the primary command execution path is single-threaded, the additional cores remain out of reach unless operators deploy more processes, shards, or instances to distribute the workload. This approach to scaling a single-threaded architecture by multiplying processes or shards has worked well enough that its architectural trade-offs are easy to overlook. But as core counts climb, those trade-offs become harder to ignore.

The industry’s hardware roadmap is exposing assumptions that remained largely hidden when CPU performance increased incrementally. And as core counts climb into the hundreds, database scalability increasingly depends on how much additional complexity is required to put those cores to work.

More cores do not mean more usable performance

For decades, software engineers could count on faster individual CPU cores as a relatively straightforward path to faster applications. This model is changing rapidly, as modern CPUs now deliver performance gains by packing more cores into each socket, while also increasing memory bandwidth and I/O capacity to keep those cores fed. To take full advantage of these advances, databases need to do more than simply run faster. They need to become better at executing work in parallel.

Consider a 96-core server running a database whose primary execution path is single-threaded. The other 95 cores aren't necessarily idle and may be running operating system tasks, networking, background work, or other processes. But the database's primary execution path isn't consuming the parallelism the hardware provides.

The traditional answer to this underutilization is to introduce more execution units. Now, more of the available hardware can be utilized. But the database architecture hasn't actually become multicore. The system has been scaled by replicating a single-core execution model. That distinction matters because the additional execution units create additional things for the infrastructure to manage. The system now needs to decide which process handles a request, how data is distributed among processes, how traffic is routed, what happens when one process becomes a hotspot, and how the system behaves when data needs to move. The more cores the hardware provides, the more pronounced and critical these questions become.

Process-per-core and sharding solve different problems

Sharding divides a dataset into partitions and distributes them across nodes. Nearly every distributed database does this, including the ones that scale well across cores. What differs is what happens inside a node.

Process multiplication increases execution parallelism within a machine. Sharding distributes data and workload across machines. In a process-per-core deployment, the two get combined: each process is both an execution unit and a shard owner, so the shard count is pinned to the core count. Doubling the cores in a process-per-core deployment may require twice as many processes, routing targets, monitoring targets, and execution contexts. This coupling is the actual issue, not sharding itself. Sharding across nodes remains the right approach to scaling beyond a single machine. The friction arises when the core count of a single socket dictates how many database processes an operator must run.

Shard rebalancing adds another source of contention. In some architectures, the same thread or process that serves client requests also participates in moving data between partitions. During a rebalance, that execution unit is doing two jobs at once: serving application traffic while reorganizing the underlying database. The extra work can raise latency precisely when the system is already under pressure.

Agentic AI magnifies the impact of this limitation

Agentic applications make this problem more visible because a single user interaction can trigger dozens of database operations: state lookups, context retrieval, tool calls, writes, and other transactional work. At scale, thousands of concurrent agents can generate numerous small, overlapping operations. Rather than processing one agentic workflow at a time, the database must handle many workflows simultaneously, each generating its own sequence of operations with different timing and access patterns. This level of concurrency puts pressure on precisely the resources that denser CPUs are designed to provide: CPU capacity, memory bandwidth, and efficient parallel execution.

AMD describes agentic AI as an end-to-end systems workload in which databases, APIs, storage, networking, and CPU resources all contribute to application responsiveness. Its current EPYC roadmap explicitly positions higher core density as important for agent orchestration, sandbox execution, tool calls, and other highly concurrent workloads. As concurrency increases, using the available cores efficiently becomes less of an optimization and more architectural table stakes for AI.

Native multicore architectures scale differently

This is where a multicore execution model takes a different approach. Aerospike uses a multi-threaded database process rather than requiring a separate database process for each CPU core, allowing the database to distribute work across the available cores. Its architecture is designed to use the available hardware directly, with non-uniform memory access (NUMA) awareness providing additional benefits on multi-socket systems (can be enabled in Aerospike). Instead of multiplying processes to consume additional cores, the database itself can schedule work across them. This reduces an entire category of coordination associated with managing multiple database processes.

NUMA awareness becomes ever more important as systems grow larger. On multi-socket machines, memory isn't equally close to every CPU core. A database that understands the relationships among threads, cores, sockets, and memory can make better use of the underlying hardware and reduce latency caused by inefficient memory access.

Adding more cores to the server doesn’t require another database process. The database can also distribute work across its own execution units without relying as heavily on an external routing layer. And each additional core doesn’t become another process that the application must account for in capacity planning.

Background operations matter, too. Aerospike uses separate threads for migration, allowing data movement to run in the background rather than competing directly with client traffic on the same execution path. The goal is to minimize the impact of cluster-management activity on application traffic. This becomes valuable as systems scale, as a database should be able to reorganize itself without compromising its ability to serve customer traffic.

Same benchmark, different scaling models

An independent benchmark conducted by McKnight Consulting Group (a database benchmarking practice that executed the test runs, contributed to the report, and reviewed and approved its findings) compared Redis and Aerospike on identical four-node clusters, with each node equipped with 32 CPU cores. Redis was configured with 32 single-threaded processes per node, for 128 processes across the cluster, while Aerospike used a single database process per node with native multicore execution.

Both configurations ran on identical hardware with identical data sets, entirely in RAM. The key difference was how each database turned those 32 cores into usable work. As server core counts continue to climb, that architectural difference becomes consequential.

The reported results were as follows:

The Aerospike configuration delivered higher throughput on the same 32-core hardware, but the more notable difference was consistency. Rate jitter was 4.4% with Redis versus 0.2% with Aerospike. That matters because applications experience individual requests, not benchmark averages. For real-time workloads, predictable performance under load can matter as much as peak throughput.

The benchmark also highlights an architectural tradeoff. The Redis configuration required 128 processes across the cluster to consume 128 cores; Aerospike required four. This doesn't mean process-based architectures can't achieve high performance. They clearly can. The tradeoff is that scaling multicore utilization through process multiplication adds operational complexity: more processes to monitor, schedule, configure, route, rebalance, and recover. Native multicore execution takes a different approach, allowing the database to use the available hardware directly rather than relying on process multiplication to get there.

Why the AMD roadmap matters

The benchmark uses 32-core machines, but server hardware is already moving well beyond that. AMD's 5th Gen EPYC Turin processors reach 192 cores per socket, while its 6th Gen EPYC Venice processors are designed to support up to 256 cores and 512 threads. AMD says Venice is being developed for cloud, enterprise, database, and AI workloads, among others. As core counts rise, the architectural tradeoffs become harder to ignore. Scaling a process-per-core model from 32 to 96 cores, for example, could mean managing three times as many execution processes. At 192 or 256 cores, the difference between a database process capable of using hundreds of cores and hundreds of single-threaded processes is no longer an implementation detail. It is a fundamentally different operational model.

A process-per-core architecture can continue to scale, but higher core densities also increase the machinery required to make those processes function as a single database. A native multicore architecture can accommodate additional cores without necessarily increasing the number of processes, routing layers, or other components that require management.

AMD, Aerospike, and Google Cloud are already collaborating on infrastructure for these workloads, with Aerospike highlighting CPU and DRAM efficiency and its multithreaded, NUMA-aware architecture.

The cost of putting more cores to work

For years, the standard answer to database capacity limits was simple: add machines, shards, or processes. This approach still works, but the underlying hardware is changing rapidly. This shifts the focus from database scalability to the operational machinery required to achieve it. As hardware becomes more parallel, architectures that rely on additional processes, shards, or routing layers can increase operational complexity as capacity increases. Architectures that use cores natively follow a different scaling curve, allowing for greater hardware capacity without necessarily increasing the number of components operators have to manage.

See the full benchmark

Download the full benchmark report to see the complete methodology, configuration, and performance results.