The cardinality wall: The hidden data bottleneck for LEO constellations

The satellite industry is entering an era defined by scale. Thousands of spacecraft are operating simultaneously in low Earth orbit (LEO), powering everything from global broadband networks to national security missions.

But as fleets expand and assets become increasingly instrumented with realtime telemetry, operators are discovering a new bottleneck that’s quickly becoming one of the hardest architectural challenges in modern space operations: the sheer volume and complexity of telemetry.

Many telemetry pipelines were designed for missions with a handful of spacecraft and were never intended to support constellations generating millions of distinct telemetry streams in real-time. As fleets grow, those systems are starting to fail in ways engineers didn’t anticipate, pushing the industry toward what could be called the cardinality wall.

The challenge is no longer simply collecting telemetry. It’s preserving enough context and fidelity to operate autonomous, software-defined fleets at scale. Operators that continue relying on architectures designed for smaller missions risk turning telemetry itself into an operational bottleneck and liability.

Telemetry is now a distributed systems problem

Previously, spacecraft telemetry was relatively manageable: A satellite transmitted health and status data during scheduled ground passes, and engineers monitored a few hundred or a few thousand parameters. Constellations fundamentally change that math.

A modern satellite bus can expose tens of thousands of telemetry signals that often stream at sub-second intervals: battery voltages, thermal sensor readings, reaction wheel speeds, payload temperatures, radiation counters, CPU utilization metrics, RF subsystem states and software events.

Multiply that by hundreds of spacecraft and operators are suddenly ingesting millions of measurements per second, each with complex structure and metadata.

Telemetry in aerospace systems carries extensive metadata: spacecraft ID, subsystem, component, sensor identifier, orbit segment, mission phase and software configuration. Every combination of those dimensions creates a unique telemetry stream. That explosion of unique streams creates high cardinality, which is where traditional ground system databases begin to break down.

The result is forcing many operators to rethink a foundational assumption of ground systems design: that telemetry infrastructure can scale incrementally alongside the fleet.

Why ground system databases start failing

Satellite operators often build telemetry infrastructure using familiar technologies like relational databases or log analytics platforms. While powerful for transactional workloads, they struggle with high-cardinality telemetry for structural reasons:

1. Most rely heavily on indexing. Telemetry queries require filtering by identifiers like spacecraft ID, subsystem and component, and as those dimensions multiply, the indexes themselves grow dramatically. The system starts spending more time maintaining indexes than processing incoming data.
2. They were built for controlled write workloads, not continuous telemetry streams. Satellite data arrives constantly and at high velocity, and as ingestion scales, strict consistency rules can slow writes, create backlogs and lead to dropped data, which are clear nonstarters in spacecraft operations.
3. Traditional databases are also poorly aligned with time-based queries. Aerospace telemetry queries are inherently time-based (for example, “show propulsion temperatures over the last five minutes”), yet traditional schemas organize data by rows or documents rather than time. The result is large scans, increased latency and delayed insight in the exact moments operators need answers.

Telemetry retention makes the problem worse

The cardinality problem compounds when operators try to retain telemetry long-term. Satellite programs increasingly store data for years or decades to replay events during investigations, compare behavior across vehicle generations, and train predictive models.

This requires systems to support both real-time ingestion and large-scale historical analysis — something few general-purpose databases handle well simultaneously. As cardinality and retention pressures compound, systems begin to fail and operators are forced into a familiar question: How do we simplify the data just to keep things running?

One example of this challenge in practice comes from Loft Orbital, which operates microsatellites and mission infrastructure in LEO. As its platform scaled, Loft needed to handle more than 500 million telemetry measurements per day, with ingestion rates reaching 10 million measurements every 10 minutes, while still supporting real-time monitoring and long-term analysis. Earlier approaches built on relational databases struggled to keep up with both the volume and structure of the data, limiting visibility into system performance. By moving to a time series-oriented architecture, Loft was able to ingest high-frequency telemetry, maintain full context across missions, and deliver faster access to both real-time and historical data — all capabilities that are essential for maintaining reliable LEO operations.

While doing the opposite of what Loft Orbital did and choosing to remove tags, downsample signals or shorten retention windows may be a short-term fix, there’s a dangerous tradeoff: loss of context.

Context is what allows engineers to correlate events across subsystems. Identifying a thermal spike in a power regulator, for example, may require correlating orbital position, solar panel orientation, battery load and payload activity. Remove that context and anomaly detection becomes significantly harder.

This becomes even more problematic for machine learning systems. Models designed to predict component failures depend on high-resolution, context-rich telemetry. Strip that away, and the signals those models rely on disappear.

For the industry, this represents more than a scaling issue. As satellite constellations become larger and more autonomous, telemetry infrastructure is increasingly becoming mission infrastructure. The systems responsible for ingesting and analyzing telemetry are no longer peripheral IT components; they directly influence operational visibility, anomaly response and ultimately mission resilience.

Breaking through the cardinality wall

Many LEO operators don’t need convincing. They’re already dealing with this in production. The first step is recognizing when the current approach has reached its limits. If teams are constantly tuning indexes, adding shards or reducing telemetry fidelity just to keep systems stable, that’s a signal the architecture itself is under strain.

A more effective starting point is to identify where cardinality is already impacting operations. This could manifest in delayed anomaly detection, slow replay of historical events or gaps in data during peak ingest periods like ground station passes. Focusing on those pressure points provides a clearer path forward than attempting a full system overhaul.

Many teams are starting to decouple parts of the telemetry pipeline rather than replacing everything at once. For instance, separating high-throughput ingestion from analytical workloads can stabilize real-time monitoring while longer-term changes are planned. Trying to handle ingestion, storage and analytics in a single system is often what creates the bottleneck in the first place.

At the same time, it’s worth revisiting any strategies that depend on throwing away data to stay operational. Downsampling or stripping metadata may reduce load, but it also introduces blind spots that tend to surface later during anomaly investigations, system validation, or design reviews. When that tradeoff becomes visible, it’s usually a sign that preserving full context needs to become a priority.

Finally, telemetry systems increasingly need to behave more like distributed infrastructure than centralized databases. Data arrives out of order, in bursts and from multiple locations across ground stations and test environments. Systems that assume clean, sequential ingestion will continue to struggle in that reality.

There may not be a single fix for the cardinality problem, but a pattern is emerging: the teams that make progress are the ones that stop patching around legacy limitations and start isolating, then redesigning, the parts of their architecture that are already under strain.

Once cardinality becomes the bottleneck, incremental tuning stops being an operational strategy. The next generation of LEO infrastructure will depend on telemetry architectures designed around the realities of scale, distribution and context preservation from the beginning.

Ian Clark is a senior sales engineer at InfluxData.

SpaceNews is committed to publishing our community’s diverse perspectives. Whether you’re an academic, executive, engineer or even just a concerned citizen of the cosmos, send your arguments and viewpoints to opinion (at) spacenews.com to be considered for publication online or in our next magazine. If you have something to submit, read some of our recent opinion articles and our submission guidelines to get a sense of what we’re looking for. The perspectives shared in these opinion articles are solely those of the authors and do not necessarily represent their employers or professional affiliations.