When you start shopping for aviation data, you run into three delivery models almost immediately, and they're often sold by the same vendors at different price points. The choices are a REST API, a bulk dataset (usually a file drop — CSV, Parquet, or a database dump), and a firehose (a persistent streaming connection that pushes every message as it arrives). Each one fits a different use case, and picking the wrong one wastes either money or engineering time, sometimes both.
This post breaks down what each model actually gives you, where the operational costs hide, and which questions to ask before signing.
REST API
What it is: You make HTTP requests and get back JSON. You ask for what you need — aircraft in a bounding box, a flight's status, weather at an airport — and get a response in milliseconds.
What it's good for: Applications. If you're building a product that shows flight positions, displays departure boards, looks up aircraft data, or computes ETAs, this is the right model. You query what you need, when you need it, and the vendor handles the infrastructure behind the endpoint.
What it costs you operationally: Almost nothing beyond the subscription. You write HTTP calls, parse JSON, and handle errors. The data is always current because you're querying live state rather than processing a file. You don't run any ingestion infrastructure.
Where it falls short: If you need every position update for every aircraft globally, an API is the wrong tool. Polling for 150,000 airborne aircraft individually is not viable, and even bounding-box queries can't cover the entire planet at the update frequency a firehose provides. APIs are for selective, on-demand access — not for hoovering up everything.
SkyLink's model: This is what we sell. REST endpoints for ADS-B positions, flight status, aircraft data, weather, airports, schedules, and more. You call what you need. Pricing is by request volume, starting at $19/month.
Bulk datasets
What it is: You receive a file — daily, weekly, or monthly — containing a large batch of records. Historical position data, aircraft registries, airline route databases, airport reference data. You load it into your own database and query it locally.
What it's good for: Analytics, research, and any workload where you need to run queries across millions of records without per-query costs. If you're training a machine learning model on historical flight tracks, analyzing traffic patterns over a year, or building a reference database of aircraft types, a bulk dataset is what you want. You pay once for the data and run as many queries as you like on your own hardware.
What it costs you operationally: Storage, an ETL pipeline, and maintenance. The dataset arrives as a file, but your application needs it in a database with indexes, and those indexes need to be designed for your query patterns. When the next file arrives, you need to merge it — upsert new records, handle deletions, deal with schema changes. For reference data (aircraft registries, airport databases), this is manageable. For position data, the volume gets large fast: a day of global ADS-B positions is tens of gigabytes compressed.
Where it falls short: Timeliness. A daily file is 24 hours stale by the time you load it. If you need live data — anything operational, real-time tracking, active alerting — a bulk dataset is the wrong model no matter how cheap it is.
What to watch for in the contract: Redistribution rights. Many bulk data licenses restrict what you can do with the data — can you build a product on it? Can you share derived statistics? Can you resell it? These restrictions are often buried in the license terms and they matter enormously if your business model depends on the data flowing through to your customers. Read the redistribution clause before you sign, not after.
SkyLink offers the Airline Database as a bulk dataset — 5,900+ airline records for a one-time purchase. For reference data that changes slowly, this model works well. For position data, we don't offer bulk exports; the API is the delivery mechanism.
Firehose feeds
What it is: A persistent connection — usually WebSocket, TCP, or a message queue — that pushes every message as it's received. Every ADS-B position update, every status change, every event. You receive them in near-real-time and decide what to keep.
What it's good for: Building your own tracking platform. If you're a company whose core product is the flight data — you're aggregating it, enriching it, and reselling it or building a tracking product — a firehose is what you need because you need everything and you need it now. Air traffic management research, large-scale surveillance, global situational awareness products.
What it costs you operationally: This is where the sticker price is misleading. The firehose itself might be priced per month, but running it requires:
- Ingestion infrastructure that can handle sustained message rates. A global ADS-B firehose pushes millions of messages per hour. You need to receive, parse, and store them without falling behind.
- Deduplication. The same aircraft heard by multiple receivers appears as multiple messages. You need merge logic. This is the problem described in the build vs buy analysis — getting it right takes real engineering.
- Storage. At firehose rates, storage costs grow quickly. Retention policy and compaction are engineering problems, not configuration settings.
- On-call. A firehose that disconnects at 3 AM needs someone to notice and reconnect it. This is a permanent operational cost.
Where it falls short: If you only need data for specific flights, regions, or airports, a firehose is wildly over-provisioned. You're receiving and processing (and paying for infrastructure to handle) millions of messages to use a few thousand of them. An API call that returns exactly what you need is cheaper by orders of magnitude in that case.
What to watch for in the contract: Message guarantees. Does the firehose guarantee delivery of every message, or is it best-effort? What happens when your consumer falls behind — does it buffer, or does it drop messages? Is there a replay mechanism for outages on your side? A firehose without delivery guarantees is a convenience, not a reliable data source.
How to choose
The decision tree is shorter than vendors would like it to be:
Do you need live data for an application? API. You query what you need, the vendor runs the infrastructure, you build your product. This covers the majority of use cases: flight trackers, logistics ETAs, airport operations tools, enterprise dashboard integrations, fleet monitoring.
Do you need historical data for analysis or ML? Bulk dataset. You pay once, load it into your own systems, and query it without per-request costs. Good for research, retroactive analysis, model training.
Do you need every update for every aircraft globally, in real-time? Firehose. But be honest about whether you actually need this — most teams that think they do are really building something that an API handles fine. The firehose is for companies whose product is the data platform, not companies that use flight data as one input.
Can you mix models? Yes, and this is common. Use the API for your live product, and license a bulk historical dataset for your analytics pipeline. The two complement each other. Just make sure the licensing terms for each are compatible with your use case.
Questions to ask any vendor
Regardless of which model you're evaluating:
- What are the redistribution rights? Can you display the data to your end users? Can you store it? Can you share derived data?
- What's the update frequency? For APIs, what's the position update rate? For bulk, how often do you get a new file? For firehose, what's the real message rate?
- What's covered by the SLA? An API with a 99.9% uptime SLA means something specific. A firehose with "best effort" delivery means something very different. Read the SLA post for what to look for.
- What does enrichment cost? Raw positions without aircraft type, registration, or airline data are often cheaper, but you'll spend engineering time building the enrichment layer yourself.
- What happens when you scale? Volume pricing matters. A per-request price that works at 10,000 requests/month might not work at 10 million.
Where SkyLink fits
We sell API access. That's the model, and we think it's the right one for most teams that need flight data as an input to their product rather than as the product itself. The free trial lets you test it before committing, and Enterprise is there when you need the SLA and the volume pricing.
If you're evaluating multiple vendors and delivery models, the benchmarking methodology applies to APIs specifically — run it against us and everyone else on your shortlist.