Achieving Scale and High Availability in Telecom Databases

The Evolving Scale of the Operator Challenge

The past two decades have transformed what it means to operate a mobile network. The shift from 2G voice systems to data intensive 4G LTE, the verbose signaling architecture of 5G (New Radio and 5G Standalone), and the approaching horizon of 6G have each imposed new and compounding demands on the infrastructure that manages subscriber state. As of late 2025, there were approximately 2.9 billion[1] 5G connections worldwide, and cellular IoT subscriptions continue to expand at scale. Global mobile data traffic is projected to reach over 140[1] exabytes per month at the end of 2025, with a growing proportion carried by 5G networks operating at a level of signaling complexity that has no precedent in prior generations.

This shift is not merely one of volume. 5G Standalone (5G SA) architectures fundamentally decompose the monolithic control plane functions of earlier generations into disaggregated, cloud-native network functions that communicate over shared data infrastructure. In this model, the subscriber database is no longer a peripheral component behind a single service, it has become a distributed state substrate that all control plane functions depend on simultaneously. The result is a qualitative change in what the database must deliver; not just capacity but spatial distribution, transactional throughput, and predictable behavior under both steady-state load and failure conditions.

Looking ahead, early 6G research envisions connectivity speeds and service densities an order of magnitude beyond current 5G capabilities. With 6G deployment timelines pointing toward the 2030s, operators planning infrastructure investments today must anticipate not only the demands of current 5G deployments, but the architectural headroom required to evolve toward these next-generation service models. In this context the database architecture is not a feature decision, it is a foundational infrastructure commitment.

Why Availability is Non-Negotiable

The consequences of database unavailability in a telecom context are direct, severe, and immediate. A subscriber database outage does not merely degrade service, it halts network registrations, disrupts active call sessions, and prevents billing records from being written. For a large mobile operator serving tens of millions of subscribers, even minutes of downtime translates into significant revenue loss and legal implications, and the broader impact extends well beyond the immediate outage window.

Industry data illustrates the financial stakes. A 2024 Oxford Economics study[2] found that unplanned downtime costs Global 2000 enterprises an average of $200 million annually. Telecom operators, as critical infrastructure providers, face an additional layer of exposure: regulatory fines for service degradation, service-level agreement penalties with enterprise customers, and the reputational damage that follows any publicly visible network disruption. In regulated markets, the compliance consequences of a subscriber database outage can persist long after service has been restored.

The industry’s historical architectural response to this challenge of deploying single-writer primary databases with hot standby replicas has reached its architectural limits. Traditional designs serialize all write operations through a single node, introduce geographic single points of failure, and depend on leader election and failover procedures that take seconds to minutes to complete. This is not a sustainable operational model for a 5G Core where control-plane functions must maintain continuous operation across multiple regions and availability zones.

Why Latency is a Capacity and Quality Driver

Database latency is not an abstract performance metric in the telecom control and service paths; it is a direct constraint on subscriber experience and network capacity. The 5G Core is architected around decomposed network functions that interact with shared data stores for every signaling procedure. A typical subscriber network registration can involve dozens of read and write operations to the subscriber database (the 5GC UDR in 3GPP terms). For operators managing geographically distributed infrastructure across wide geographical areas, the physics of wide-area networking impose hard limits. Even a small increase in per-request latency accumulates into visible degradations of subscriber experience, turning what would normally be a sub-second registration into a multi-second one.

Three Simultaneous Requirements, One Architecture

Taken together, the operational realities of modern telecom deployments define a rigorous and demanding problem space. The database architecture that supports a large-scale mobile operator must simultaneously satisfy three dimensions of scale:

• Spatial scale: active operation across multiple sites and geo-regions, separated by wide-area network links with variable latency, jitter, and the possibility of complete network partitions.
• Traffic scale: sustained high-throughput transaction processing with predictably low response times, including sudden and unpredictable traffic spikes driven by subscriber activity or network events.
• Operational scale: continuous availability through software and hardware upgrades, planned maintenance, site additions, and partial failures. These need to be treated as routine operational conditions rather than exceptional events.

No general-purpose database engine was designed to optimize this specific combination of constraints. The telecom subscriber data layer has requirements that differ meaningfully in character from the enterprise transactional workloads, web-scale content platforms, and financial services databases. The telecom data layer demands deterministic behavior under failure, fine-grained control over consistency trade-offs, and the operational transparency to allow engineering teams to reason about the system’s state without resorting to manual reconciliation.

This is the problem space that Enea’s Stratum was engineered to address. Developed in close collaboration with Tier-1 operators in North America and Europe and continuously evolving through production deployments at scale, the Stratum embodies a set of deliberate architectural choices rooted in the formal trade-off frameworks that govern all distributed systems. The following sections introduce these frameworks and explain how they directly inform Stratum’s design.