Every team that needs live aircraft positions has the same meeting. Someone points out that ADS-B is an open broadcast, that receivers are cheap, and that there are community feeds you can join — so why are we paying a vendor? It's a fair question, and the honest answer is that the signal is free but the pipeline is not. This post breaks down what running your own ADS-B ingestion actually costs, so you can make that call with numbers instead of instinct.
We'll say up front: we sell an ADS-B API, so we're not a neutral party. What follows is the same component-by-component breakdown we'd want if we were on your side of the table — including the cases where building genuinely is the right answer.
What "an ADS-B pipeline" actually contains
The thing people underestimate is that ingestion is maybe 15% of the work. A production pipeline is:
- Feed acquisition. Either your own receivers (hardware, sites, power, connectivity, physical maintenance) or agreements with feed providers and community networks. Coverage is a function of receiver density, and you don't control where volunteers put theirs.
- Ingest and normalization. Decoding messages, handling malformed frames, normalizing units and timestamps across sources that disagree with each other.
- Deduplication and merge. The hard part. The same aircraft is heard by many receivers at once; you must merge those into one authoritative track, resolve conflicting positions, and decide which fix wins.
- Enrichment joins. A raw message gives you a hex address, not "United 787." You need an aircraft registry (registration, type, operator) and a route source, both kept current — the enrichment problem in its own right.
- Storage and retention. Position data is relentless and high-volume. Retention policy, partitioning, and compaction become real engineering decisions fast.
- Serving layer. Your app needs geographic queries — bounding box, radius, filters — with acceptable latency under concurrency. That's a spatial-indexing problem, not a
SELECT *. - Monitoring and on-call. Feeds die quietly. A receiver drops and your coverage develops a hole nobody notices until a customer reports it. Someone has to own that pager.
Where the hidden costs actually are
Hardware is the line item everyone budgets and the one that matters least. The costs that surprise teams:
- Coverage you can't buy with money alone. ADS-B is line-of-sight. Oceanic, polar, and sparsely-populated regions need satellite-based reception or they're simply dark. No amount of terrestrial receivers fixes an ocean, and low-altitude coverage is thin nearly everywhere outside dense receiver clusters.
- Dedup quality is a long tail. Getting a merged track that looks right 95% of the time takes weeks. The last few percent — jitter between receivers, clock skew, aircraft with intermittent transmitters — takes quarters, and it's exactly what your users notice.
- The registry rots. Aircraft change operators, registrations get reassigned, new airframes appear daily. A registry snapshot is wrong the week after you import it, so you're now also running a data-maintenance pipeline.
- On-call is forever. This is the cost nobody models. A pipeline that must be current is a 24/7 service with an escalation path, runbooks, and someone's weekend.
- Opportunity cost. Every engineer-week on ingestion plumbing is a week not spent on the product your customers actually pay for.
A TCO model you can re-run
Here's a framework rather than a quote — plug in your own salary and infrastructure numbers, because they vary enormously by region and scale. The point isn't our figures; it's which rows dominate.
| Cost line | Year 1 (build) | Ongoing (build) | Buy |
|---|---|---|---|
| Receiver hardware / feed access | One-off + siting | Replacement, connectivity | Included |
| Initial engineering (ingest, dedup, serving) | The dominant line — multiple engineer-months | — | Days of integration |
| Enrichment data (registry, routes) | Licensing or scraping + maintenance | Continuous | Included |
| Infrastructure (compute, storage, egress) | Modest at small scale | Grows with retention | Included |
| Monitoring & on-call | Setup | Permanent headcount cost | Vendor's problem |
| Coverage gaps (oceanic/remote) | Often unsolvable in-house | — | Vendor's coverage |
| What dominates | Engineer-months | On-call + maintenance | Subscription |
Run the arithmetic honestly and the comparison usually isn't "hardware vs subscription" — it's "several engineer-months plus a permanent on-call rotation" vs "a line item." At SkyLink's scale that line item starts at $18.59/mo for self-serve tiers and moves to negotiated volume pricing at Enterprise; either way it is generally cheaper than one engineer-week per month, and that's before coverage.
When building genuinely wins
We'd rather you make the right call than buy something you don't need. Build when:
- You need one small, specific area — a single airport or metro. One receiver on your own roof, feeding your own app, is a great weekend project and genuinely cheap. Our Python tracker tutorial and Raspberry Pi departure board are exactly this.
- The raw signal is the product — you're doing research on the protocol itself, or building receiver hardware.
- You have hard sovereignty or air-gap requirements that forbid an external dependency outright.
- You already run the infrastructure for another reason and the marginal cost is genuinely near zero.
Buy when you need broad or global coverage, when position data is an input to your product rather than the product, or when you need someone contractually accountable for it — which is the subject of flight data SLAs.
Before you decide either way
Whichever direction you lean, benchmark it. Coverage claims are easy to make and easy to test, and the numbers frequently surprise people on both sides of the build/buy line — we publish the full evaluation methodology so you can run it against us and everyone else.
SkyLink API gives you a free tier of 1,000 requests/month to benchmark against before committing engineers to a pipeline. It's available through the free trial — sign up, grab a key, and price the alternative properly.