The Best Database for Aerospace in 2026: An Honest Comparison

Most "best database for aerospace" lists are really time-series database lists with a rocket on the header image. That is not useful, because the thing that breaks aerospace data projects is rarely the database's benchmark number. It is the ground-station pass that closes before the backlog finishes uploading. It is the flight-test archive that has to be readable in 2046. It is the ITAR boundary that rules out the managed cloud product you just evaluated, and the CCSDS packet stream that no general-purpose database can ingest without a mission-control layer in front of it.

I worked at InfluxData. I now run Basekick Labs, where we build Arc, an open, SQL-native time-series database for telemetry you need to keep, which we sell into aerospace and defense. I have a horse in this race and I will say so whenever it matters. This post covers nine real options, including two that are not databases in the conventional sense but are what aerospace teams actually deploy, and I will be specific about where each one wins and where it does not.

This is the third post in a series. The time-series comparison evaluates engines generally, and the IoT comparison evaluates them against edge and MQTT constraints. Aerospace constraints are different enough to reorder the list again, and to add entries that appear on neither.

Aerospace is four workloads, not one

Before comparing anything, be honest about which of these you are.

Satellite operations. The defining pattern is burst-then-silence. A LEO satellite is in view of a given ground station for a few minutes per orbit, dumps everything it collected since the last contact, then disappears for the better part of an hour. Loft Orbital describes ingesting 10 million measurements every 10 minutes across its fleet. InfluxData's write-up of Eutelsat OneWeb puts each satellite at more than 50,000 values, with the fleet producing over a million data points per second and more than 15 million unique series. Those are vendor numbers, but the shape is right: high cardinality, bursty, and years of retention.

Launch. From T-10 minutes to engine cutoff, a launch produces comparatively little data by volume, on the order of gigabytes in the programs we have worked with. The requirements around it are the strictest on this list: zero loss, real-time streaming to the control room, and instant replay of the whole timeline afterward. The database is a small part of a launch stack. The part it plays is durability and replay.

Flight test. The high-rate end. Flight-test instrumentation records to IRIG 106 Chapter 10 files, and modern programs track tens of thousands of parameters at kilohertz rates. The F-35 program's quick-reaction instrumentation package collects close to a terabyte per flight. This data is usually post-processed from recorder files rather than streamed, which means batch load performance matters more than streaming ingest.

Mission control archives. Spacecraft speak CCSDS Space Packets, described by XTCE or ECSS PUS definitions. The archive of record is whatever your mission-control software writes decommutated parameters into, and it has to stay queryable for the life of the program. A GEO communications satellite is designed for around 15 years. Voyager 1 is still returning data 49 years after launch.

Most real programs are two or three of these at once, and the database that is right for flight test is often wrong for the constellation.

The uncomfortable truth about CCSDS

Let us clear this up first, because it shapes every architecture decision downstream.

No general-purpose database ingests CCSDS packets. Not InfluxDB, not TimescaleDB, not ClickHouse, not Arc. Turning a packet into named, calibrated parameters (decommutation) is the job of a mission-control layer: Yamcs, OpenC3 COSMOS, NASA's AIT, or a commercial system like Kratos EPOCH. The database question in aerospace is really "what does that layer write into, and what do I run analytics against afterward."

The production pattern in 2026 looks like this:

spacecraft → ground station → frames / packets
           → mission control (Yamcs, COSMOS, AIT, vendor MCS)  [decommutation]
           → parameter archive                                  [archive of record]
           → analytics store                                    [fleet trends, ML, notebooks]
           → Grafana / Open MCT / Jupyter

Some teams make the parameter archive and the analytics store the same thing. Most end up running two, because the archive that is good at replaying a pass is rarely the store that is good at "show me battery degradation across 200 satellites over 18 months." Two of the entries below are archives. The rest are candidates for the analytics store, or for both roles if your scale allows it.

What actually matters when choosing

Rank these against your own program before you look at a benchmark.

1. Rate profile. Bursty pass downlinks, sustained kilohertz flight-test streams, and batch loads of recorder files stress different parts of an engine. Ask which one you have.

2. Program lifetime and data format. Your telemetry will outlive the database you choose today. NASA-funded missions have been required to archive in PDS4 since 2011, and the agency's SPD-41a policy pushes mission data toward open, machine-readable formats. The commercial equivalent is simpler: if the vendor goes away in year nine of a fifteen-year program, can you still read the files?

3. Deployment boundary. ITAR-controlled technical data cannot sit in infrastructure accessible to foreign persons. The 2020 end-to-end encryption carve-out makes some cloud use possible, and AWS GovCloud carries FedRAMP High and DoD IL5, but many programs still run on-premises or air-gapped. For defense contractors, the CMMC final rule became effective November 10, 2025, with Level 2 third-party assessments phasing into solicitations from November 2026. A database that cannot run without an internet connection is out.

4. Metadata joins. Telemetry is meaningless without the spacecraft registry, calibration coefficients, command history, and ground-station schedule. Loft Orbital keeps a separate Postgres for exactly that. If your analytics store cannot join against it, you will stitch in application code forever.

5. Cardinality. Satellite ID times subsystem times parameter times ground station multiplies fast. Fifteen million series is a vendor-reported number for one constellation. Engines with a series-index ceiling fall over here.

6. License. AGPL, source-available, and proprietary licenses each get vetoed by some legal departments. OpenC3 COSMOS left AGPL in March 2026 for a modified Elastic License. TimescaleDB's most-wanted features are under the Timescale License. Find out on day one.

Scale bands

For reference, SpaceX said in 2020 that Starlink was generating more than 5 TB of telemetry per day, and a 2021 engineering profile described its store as Kafka, HBase, and HDFS. Almost nobody reading this is in that band. Most programs are in the first two.

The nine aerospace databases, compared

1. InfluxDB 3

InfluxDB 3 Core and Enterprise reached GA in April 2025, rebuilt in Rust on Arrow and DataFusion, with Parquet as the storage format. That last part changed this summer, and for aerospace it is the most important thing in this section.

Why it wins for aerospace. It has more published spacecraft-operator case studies than any other general-purpose database on this list, and that matters when you are arguing for a stack in a design review. The mission-control tools below have longer user lists, but as C2 systems, not analytics stores. Loft Orbital runs it for spacecraft telemetry. Thales Alenia Space uses it to ingest satellite data and replay it for ML fault detection. Epsilon3, the aerospace operations platform, runs InfluxDB 3 Enterprise on Kubernetes for 1,000 Hz telemetry streams after a relational database degraded as series counts grew. LeoLabs keeps three years of full-resolution telemetry from its radar sites. NASA's AIT ground-data toolkit ships an InfluxDB backend, and Caltech's Lunar Trailblazer ground system documents AIT feeding InfluxDB, visualized in Open MCT.

Telegraf is the ingest bridge the industry already knows, and InfluxData has published a Chapter 10 flight-test pipeline pattern. InfluxData says the v3 columnar engine removes the cardinality ceiling that made v1 and v2 struggle on fleet telemetry. Enterprise supports an offline license file for air-gapped deployment.

Where it falls short. Core, the free edition, is built for recent data. Its public alpha limited a query plan to 432 Parquet files, a 72-hour range, and Core remains the recent-data tier; check the current limit before assuming it changed. Either way it is the opposite of a fifteen-year archive. Long-range historical query, high availability, and read replicas are Enterprise, priced per core. Three incompatible generations (1.x, 2.x with Flux, 3.x with SQL) are all still supported.

Then there is storage. Since the 3.0 rewrite, "your data is in Parquet" was a load-bearing part of the InfluxDB 3 pitch, and it was the reason I could recommend it to a program thinking in decades. InfluxDB 3.11, released July 30, 2026, made a new proprietary columnar format, .pt files from the "Pacha Tree" engine, the default for new clusters. Existing clusters stay on Parquet until an operator opts in, migration runs in a hybrid mode, and the files are unreadable by earlier versions. Parquet is now a bulk import and export feature rather than the format your data lives in. For a fifteen-year archive that is a different product: you can still get your telemetry out, but it is an export job on a volume that may be enormous, not a directory another engine can read in place. Decide on purpose whether that trade is acceptable before you standardize on it.

The Eutelsat OneWeb numbers above come from InfluxData only; an independent profile of OneWeb's data platform names Snowflake and DataOps.live, not InfluxDB. We worked through the Enterprise pricing math in our TCO comparison.

CCSDS path. Yamcs, COSMOS, or AIT in front, or Telegraf for decoded streams.

Best for. Teams that want the most-referenced option for satellite telemetry, are Telegraf-shaped already, and can budget Enterprise for the archive tier.

2. TimescaleDB and PostgreSQL

TimescaleDB is a PostgreSQL extension. The company rebranded to Tiger Data in June 2025.

Why it wins for aerospace. Joins. Your spacecraft registry, calibration tables, command log, pass schedule, and anomaly tickets are almost certainly in Postgres already. Putting telemetry next to them makes "which satellites with the revision-B power board show this thermal signature" a single query. Plain Postgres has mission heritage of its own: the SVOM mission's French Science Center stores raw telemetry and calibration data in dedicated PostgreSQL servers, and Rocket Lab's ground software job postings list InfluxDB or PostgreSQL as the expected database.

The compliance story improved this year. TimescaleDB Enterprise, announced April 2026, is explicitly built for on-premises and air-gapped environments, names defense as a target industry, and adds HA failover and point-in-time recovery. Every Postgres tool, driver, and hire works on day one.

Where it falls short. The only aerospace-adjacent customer story I could find is Speedcast, monitoring 12,000+ Starlink terminals at about 20 GB per hour. That is satcom infrastructure, not spacecraft telemetry, and I found no spacecraft, launch, or flight-test deployment on the record. Multi-node scale-out was dropped in version 2.14, so a single primary plus read replicas is your ceiling. The features you want most (columnar compression, continuous aggregates, and the policy scheduler) are under the Timescale License, which is source-available and forbids offering them as a managed service.

CCSDS path. Mission-control layer in front, then Telegraf or direct inserts.

Best for. Programs already on Postgres, at small to medium scale, whose analysis is metadata-heavy. This is the right default for more university and single-spacecraft missions than any other entry here.

3. Yamcs

Yamcs is open-source mission-control software from Space Applications Services in Belgium. It is on a database list because for many programs its archive is the database.

Why it wins for aerospace. It speaks the protocols natively: CCSDS frame and packet processing, PUS, XTCE definitions. The archive is a purpose-built parameter store on RocksDB, with delta-of-delta timestamps and Gorilla compression for 32-bit floats, designed for pass replay. The heritage is real and named. Users listed on the project's site include NASA, ESA, CNES, DLR, Airbus Defence and Space, MBRSC, Astrobotic, Pixxel, and Sierra Space, and the vendor cites NASA VIPER, the European Robotic Arm, and Astrobotic's Peregrine as missions. It is AGPL, pure Java, and runs anywhere a JVM does, including behind an air gap. Open MCT's quickstart pairs with it.

Where it falls short. It is not an analytics engine. The project's own documentation explains it rejected relational storage because of the update rates its archive indices need, and the trade is that fleet-wide analytical SQL is not what the archive does. Export is CSV, through the web UI, HTTP API, or Python client; there is no Parquet or Arrow export. 64-bit values are stored uncompressed. If you need cross-satellite trend analysis or ML training sets, plan on a second store downstream.

CCSDS path. Native. This is the layer everyone else needs in front of them.

Best for. The archive of record for spacecraft that speak CCSDS and PUS, especially in ESA-adjacent programs, paired with an analytics store for anything beyond replay.

4. OpenC3 COSMOS

OpenC3 COSMOS is the successor to Ball Aerospace COSMOS, the other widely deployed open-core command-and-control system.

Why it wins for aerospace. Breadth of adoption in the US. The vendor lists NASA, Lockheed Martin, General Atomics, Blue Origin, Boeing, Sierra Space, Sandia, and the US Space Force among users, and Quindar builds its C2-as-a-service on it. COSMOS 7, released March 2026, replaced the old JSON decom log files with a bundled time-series store for decommutated data and removed the reducer microservices, claiming an order of magnitude faster retrieval. Raw packets are still kept as gzipped binary files rolled every 10 minutes or 50 MB into S3-compatible buckets, which means the bit-exact record survives whatever happens to the derived store.

Where it falls short. The 7.0 release changed the license from AGPL to the COSMOS Builder's License, a modification of Elastic License 2.0 that prohibits offering COSMOS as a hosted service. Core stays free; Enterprise starts at $33,000 per year. The 7.0.0 release notes themselves tell users to skip to 7.1 because of issues with the new store, so treat the current archive tier as young. Like Yamcs, it is a mission-control product, and fleet analytics across years of data is something you build next to it.

CCSDS path. Native.

Best for. US programs that want a supported C2 system with a built-in archive and are comfortable with a non-OSI license.

5. Elasticsearch

Elasticsearch is a search engine that some teams use as a telemetry store because it is already there for logs. NASA JPL is the reference Elastic cites for Curiosity rover telemetry.

Where it falls short. It is a document search engine, not a columnar analytical database. Elastic conceded as much when it added a columnar mode in 9.5, and we wrote up what that retrofit does and does not change. That post is the whole argument, so I will not repeat it here.

CCSDS path. Mission-control layer, then Logstash or Beats.

Best for. The log and event tier next to a numeric store, not the numeric store itself.

6. ClickHouse

ClickHouse is a general-purpose columnar OLAP database.

Why it wins for aerospace. At the top of the large band, it is the most battle-tested open-source engine for slicing tens of billions of rows arbitrarily, and it reads and writes Parquet. If you are building the fleet analytics tier for a very large constellation and have the platform team to run it, it belongs on the shortlist.

Where it falls short. I could not find a single public aerospace, space, or defense customer on ClickHouse's user stories, and the only signal is a job-posting snippet (a SpaceX database reliability role that appears to list ClickHouse alongside PostgreSQL and Oracle). Time is just another column rather than the storage organizer, so pass replay and last-known-value need workarounds, and its operational weight is the wrong shape for a ground station rack.

CCSDS path. Mission-control layer, then Kafka or direct inserts.

Best for. The central analytics tier of a very large program, next to something lighter as the archive.

7. kdb+ and KDB-X

kdb+, from KX, is the time-series engine of the finance world, and it has a defense story.

Why it wins for aerospace. Lockheed Martin's Skunk Works partnered with KX in 2024 on a real-time situational awareness model for joint all-domain command and control. KX markets explicitly to aerospace, defense, and space, including air-gapped deployment. The engine is very fast on as-of joins between sensor streams, which is exactly the shape of correlating telemetry with commands. KDB-X, GA in April 2026, added SQL interop and a Community Edition licensed for commercial and offline use.

Where it falls short. The Lockheed work is C2, not vehicle telemetry storage, and I found no flight-test or satellite archive on the record. The q language is a hiring constraint. The Community Edition caps at 16 GB of RAM and a single instance; beyond that it is a commercial license, and the storage format is proprietary.

CCSDS path. Mission-control layer, then custom feed handlers.

Best for. Programs with a KX relationship or C2 fusion workloads where as-of join speed dominates.

8. Sift

Sift is not a database. It is a telemetry platform founded by SpaceX alumni, and I am including it because it is what a growing number of NewSpace teams buy instead of choosing a database at all.

Why it wins for aerospace. It is built for exactly this. It takes tens of thousands of channels at rates up to 10 kHz and imports CSV, ULOG, ROS, TDMS, Parquet, and HDF5 files natively. Deployment options include on-premises, GovCloud, classified, and disconnected environments. Named customers include K2 Space, Impulse Space, Astranis, JetZero, and ULA, and it raised a $42M Series B in March 2026.

Where it falls short. You do not get to pick, see, or run the database underneath, and the company does not disclose it. Your exit is a Parquet export and a Grafana plugin. For a hardware startup in test campaign mode that is a fine trade. For a fifteen-year program with an archive obligation, decide up front whether a SaaS vendor owning the store is acceptable.

CCSDS path. File import and SDKs; decommutation is still yours.

Best for. Test stands, flight test, and early-stage vehicle programs that want a product, not a stack.

9. Arc

Arc is an open, SQL-native time-series database for telemetry you need to keep. I built it after leaving InfluxData. The SQL is PostgreSQL-compatible, storage is native Apache Parquet on S3, Azure Blob, MinIO, or local disk, and it ships as a single static Go binary. It has been public since October 2025.

I am including it because on two of the six criteria above, format longevity and deployment boundary, it is the strongest option here, and on metadata joins it is competitive with the Postgres options. It is also the youngest, and I will be specific about what that costs you.

Why it fits aerospace. Start with the data format, because program lifetimes make it the criterion that decides the most. Arc writes plain Parquet, partitioned by time, to storage you own. If Basekick Labs is gone in year nine, Spark, Polars, ClickHouse, and every lakehouse engine read those files as-is, with no export step. Since Arc 26.09.1, Arc can also expose that same Parquet as an Apache Iceberg table without copying it, on local-disk deployments in this first release. We made the long-form case for this in Aerospace data has a storage problem, not a speed problem, and the architecture patterns we see, from a single ground station to a hybrid ITAR-plus-cloud layout, are in why aerospace teams choose Arc for satellite telemetry.

The deployment boundary is the second criterion. One binary with no JVM, no Postgres, and no license server means it runs inside an ITAR boundary, on GovCloud, or on an air-gapped rack without anything phoning home. 26.09.1 added Edge Sync, designed for the ground-station and DDIL case. The edge node initiates every transfer, so a site behind NAT works, and a pass streams newest-first, so a contact window that closes mid-backlog has already delivered the freshest telemetry. For a site with no network at all, the same mechanism writes a signed bundle to removable media and brings a signed receipt back on the same drive. Every file is verified by SHA256 and redelivery is a no-op. The design post has the details, and the two-tier reference architecture for MOSA programs shows how it is deployed.

Third, analytics. Full analytical SQL, including ASOF JOIN for correlating a telemetry stream against a command log, window functions, and joins against whatever metadata table you keep in Arc (load the registry once through bulk CSV or Parquet import). Arc also speaks TLE natively: post a two-line element file to a dedicated endpoint and Arc parses it, computes semi-major axis, period, apogee, perigee, and orbit class, and stores it as queryable Parquet. Our satellite tracking demo is built on public Space-Track.org data.

On ingest, Arc sustains 34M records/sec via the MessagePack columnar protocol on the same benchmark that did 20.6M before 26.09.1. Be appropriately skeptical of that number: it is a first-party benchmark on an Apple M3 Max, not server hardware, and it is not third-party validated. Line Protocol, MQTT, and bulk Parquet and CSV import are the other paths, which covers Telegraf pipelines and batch loads of decoded flight-test files.

Where it falls short. Arc does not decommutate CCSDS. It sits behind Yamcs, COSMOS, AIT, or Telegraf, exactly like every other analytics store here. We work with aerospace and defense teams today, but they are under NDA and I cannot name them, so treat that as a first-party claim until one of them publishes. Our satellite dashboard is a live demo on open data, not a customer deployment, and I would rather say so than let it read as a logo. Edge Sync in the open-source release is operator-triggered through the API; the scheduled agent that automates it is an Enterprise feature that lands later. Clustering and HA are Enterprise. The license is AGPL-3.0, which is intentional, and Arc Enterprise is commercially licensed for legal departments that will not accept it, with RBAC over LDAP, SAML, or OIDC, structured audit logging, and tiered storage to archive-class object storage.

CCSDS path. Mission-control layer or Telegraf in front. TLE is native.

Best for. Programs that treat telemetry as a multi-decade asset and want it in a format they own, that must deploy inside an ITAR boundary or across DDIL links, and whose analysts want real SQL over the fleet. Arc is open source and free; a Docker container behind your existing Yamcs or COSMOS instance is enough to evaluate it.

Decision matrix

The query patterns you will actually write

Four patterns cover most of aerospace analysis. Check your shortlist against all four.

Pass replay. "Show me every parameter between AOS and LOS on that contact, in order." Yamcs and COSMOS do this natively. In an analytics store it is a time-range scan, and out-of-order arrival matters: a pass delivers data collected over the previous ninety minutes, timestamped in the past. Engines that assume monotonic time will hurt.

Fleet-wide trend. "Battery minimum voltage per satellite per day for the last 18 months, worst first." This is a GROUP BY across hundreds of series over a long range, and it is where columnar engines (InfluxDB 3, ClickHouse, Arc) separate from the archives.

Command-to-telemetry correlation. "For every thruster fire command, what was the tank pressure at the nearest telemetry sample before and after?" That is an as-of join, and kdb+ built a career on it. Arc has ASOF JOIN. ClickHouse has it too, and Postgres does it with LATERAL. Metrics-only engines cannot.

Limit checking and last known value. "Which parameters are outside their red limits right now?" Mission-control layers own this in real time. For the historical version, you want DISTINCT ON or an equivalent; general OLAP engines need argMax gymnastics.

If pattern two or three is on your roadmap, do not pick an archive alone, and do not pick a metrics-only engine.

What I left out, and why

VictoriaMetrics, GreptimeDB, TDengine, MongoDB, and Cassandra all appear in the general time-series and IoT comparisons. I searched for public aerospace telemetry deployments of each and found none. VictoriaMetrics is metrics-only with no SQL, which rules it out of the fleet analytics tier regardless. Prometheus is a monitoring tool with a retention model that assumes old data is disposable. AWS Timestream for LiveAnalytics closed to new customers on June 20, 2025.

What changed in 2025 and 2026

• OpenC3 COSMOS 7 (March 2026) moved decommutated data into a bundled time-series store and moved the project off AGPL. If you standardized on COSMOS partly because it was OSI open source, re-read the license.
• TimescaleDB Enterprise (April 2026) gave Postgres shops an air-gap and defense story they did not have before.
• KDB-X (April 2026) added SQL interop and a commercially usable, offline-capable Community Edition.
• InfluxDB 3 Core and Enterprise GA (April 2025) is, per InfluxData, the end of the cardinality ceiling that made v1 and v2 painful for fleet telemetry. The Docker latest tag flips to 3 Core on September 15, 2026, which will surprise anyone with an unpinned deployment.
• InfluxDB 3.11 (July 2026) made a proprietary .pt storage format the default for new clusters. Parquet became an import and export path instead of the on-disk format. If "open storage" was on your requirements list when you picked InfluxDB 3, re-check it.
• CMMC 2.0 became enforceable for DoD contracts on November 10, 2025, with Level 2 third-party assessments arriving in solicitations from November 2026. "Where does the telemetry live" is now a contract question.
• Arc 26.09.1 (September 2026) shipped Edge Sync with an air-gap transport and Iceberg export.

How to choose an aerospace database

Answer six questions and most of the field disappears:

1. Do you need an archive of record that speaks CCSDS and PUS? → Yamcs or COSMOS. Everything else goes behind it.
2. Already on Postgres, single spacecraft or small constellation, metadata-heavy analysis? → TimescaleDB.
3. Want the most-referenced satellite telemetry stack and can budget for Enterprise? → InfluxDB 3.
4. Test stand or flight-test campaign, and you want a product rather than a stack? → Sift.
5. Very large fleet, dedicated platform team, arbitrary slicing over tens of billions of rows? → ClickHouse.
6. Multi-decade program, data must stay in a format you own, deployment inside an ITAR boundary or across DDIL links, and analysts who want SQL over the fleet? → Arc.

That sixth case is more common than the vendor landscape suggests, because aerospace telemetry outlives every database on this list. A satellite launched this year will still be reporting in 2041. Yamcs's archive is RocksDB in a layout only Yamcs reads. InfluxDB 3 stored Parquet until 3.11; new clusters now write a proprietary format and Parquet is an export job. Arc writes plain Parquet to storage you own, laid out to be read directly by Spark, Polars, ClickHouse, or any Parquet reader, and on local storage can present it as an Iceberg table. That turns "we are switching" from a migration project into a decision.

Then design for two tiers. Almost every successful aerospace data architecture is a mission-control archive plus an analytics store, not one engine trying to be both.

Finally, do not pick from a blog post, including this one. Shortlist two. Replay a real week of passes, at your real cardinality, with your real queries, on both. Measure ingest during the burst, not the average, p99 on your fleet-trend query, and how much of your test data you can read back with a tool that is not the database.

FAQ

What database do satellite operators use? The best-documented answer is InfluxDB for the telemetry store, with a separate Postgres for spacecraft metadata (Loft Orbital's published architecture), behind a mission-control layer such as Yamcs, COSMOS, or AIT that owns decommutation. Larger operators build custom stacks; SpaceX described Kafka, HBase, and HDFS for Starlink in 2021.

What is the best satellite telemetry database? There is no single answer, which is the point of this post. InfluxDB 3 is the most-referenced analytics store for satellite telemetry. Yamcs and OpenC3 COSMOS are the archives of record that speak CCSDS. TimescaleDB fits metadata-heavy analysis on small fleets. Arc fits programs that need the archive in a portable format inside an ITAR boundary. Shortlist two and replay a real week of passes on both.

Can any database ingest CCSDS packets directly? No general-purpose database does. Yamcs and OpenC3 COSMOS process CCSDS frames and packets natively and write to their own archives. Every analytics store on this list sits behind one of them, or behind Telegraf on an already-decoded stream.

Can I keep ITAR-controlled telemetry in a cloud database? Sometimes. Since 2020, end-to-end encrypted technical data in the cloud is not an export if the provider cannot access the keys and the data stays out of prohibited countries, and GovCloud regions carry FedRAMP High and IL5. Many programs still choose self-hosted or air-gapped deployment because it is simpler to defend in an audit. InfluxDB 3 Enterprise, TimescaleDB Enterprise, and kdb+ document offline operation, and Yamcs, COSMOS, and Arc are self-hosted with no call-home requirement.

What is the best database for flight-test data at kilohertz rates? Flight-test data is usually post-processed from IRIG 106 Chapter 10 recorder files, so batch load speed and channel count matter more than streaming ingest. Sift is purpose-built for it. Epsilon3 documents 1,000 Hz streams on InfluxDB 3 Enterprise. Arc's bulk Parquet and CSV import handles decoded recorder output, and its columnar ingest path handles decoded streams.

How long do I need to keep telemetry? For the life of the program, and often longer. A GEO communications satellite is designed for roughly fifteen years and frequently flies past that. NASA-funded science missions must archive in PDS4. The practical rule: choose a storage format you would be comfortable reading with a different tool in twenty years.

Which aerospace databases are open source? Yamcs (AGPL), InfluxDB 3 Core (MIT or Apache), TimescaleDB (Apache 2.0 core, Timescale License for the advanced features), ClickHouse (Apache 2.0), and Arc (AGPL) are open source. OpenC3 COSMOS Core is free but moved to a non-OSI license in 7.0. kdb+ and Sift are commercial.

---

This post will be updated quarterly. Last updated September 2026. If something here is wrong or out of date, tell me on GitHub or in Discord.

---

Related reading:

• 6 Best Time-Series Databases in 2026
• The Best Database for IoT in 2026
• Aerospace Data Has a Storage Problem, Not a Speed Problem
• Designing Arc Edge Sync for the Tactical Edge
• Arc Now Speaks TLE
• Why Aerospace Companies Are Choosing Arc for Satellite Telemetry
• Parquet vs Proprietary Formats
• InfluxDB Had Open Storage. Its New Engine Walks Away From It.

Explore Arc:

• Arc for Aerospace and Defense
• Arc documentation
• Compare Arc vs InfluxDB
• Compare Arc vs ClickHouse
• Star Arc on GitHub

---

About the author. I am Ignacio Van Droogenbroeck, founder of Basekick Labs and an ex-InfluxData engineer. I have been working with time-series and telemetry data since 2018, and for the past year a lot of that has been with satellite operators, launch companies, and defense programs. I built Arc because I believe telemetry infrastructure should be built on portable, columnar formats rather than proprietary engines, and nowhere is that more true than in an industry that measures programs in decades. The other eight options on this list are all real choices for the right team. If yours is a program whose data has to outlive its vendors, I would like you to try Arc.