business|Aug 23, 2026

Why graphs belong in your airline's AI strategy

Braulio Ríos

Technical Account Manager

Braulio Ríos

Technical Account Manager

A table can tell you that 5 flights were delayed today. It can't tell you why, or which flights are about to fall next. That information exists in your operation. It just doesn't exist in your data model.

We recently attended an airline industry conference and came back with a clear signal: a lot of airlines are sitting on exactly this kind of problem, the kind graphs are built to solve, and almost none of them know it.

The leaders we talked to were describing cascading delays, crew dependencies, passenger behavior, loyalty activity, fraud patterns, and maintenance constraints. Very different problems, with one thing in common: the answer isn't in any single data point. It lives in the relationships between many of them.

That is the whole idea behind graphs. You model the things you care about (passengers, flights, airports, bookings, crews, aircraft, loyalty accounts) as nodes, and the relationships between them ("traveled on", "operated by", "redeemed for", "depends on") as edges. An airline already operates as a graph. It just stores and analyzes that reality as if it were a pile of disconnected tables.

This article has one job: to help you recognize a graph problem when you see one.

What is a graph?

A graph is a data model built on two ideas: entities and relationships between them.

Entities are the things you can "name”, for example, a passenger, a flight, an airport, a booking, an aircraft, a supplier, a loyalty account. In graph terms, these are called nodes.

Relationships describe how those entities connect: a passenger made a booking, a flight departs from an airport, an aircraft operates a route, a customer opened a claim after a disruption. These are called edges.

That's it. The power is in what becomes easy to ask once relationships are first-class citizens of your data, instead of something you have to reconstruct every time.

Why not just use tables?

Fair question. Relational databases literally have "relational" in the name, so of course they handle relationships too. The difference is how. In a relational database, relationships are reconstructed on the fly through foreign keys and joins. In a graph database, the relationships are part of the structure itself.

A quick example. Say you want to answer: which passengers share a booking with someone from a different country? In a graph, two passengers "travel together" whenever they share a booking. That's a relationship you never stored explicitly, but can simply look for. In Cypher (a graph query language), the whole question fits in three lines:

You don't need to read code to notice the important part: the query looks almost exactly like the question you asked. Two arrows converging on the same booking. That's the relationship.

For those who want to look under the hood, the same question in SQL means joining the purchases table to itself:

Two passengers on one booking is a many-to-many relationship. In tables, that always means a junction table and a self-join. In a graph, it's just two edges into the same node.

Any two passengers sharing a booking are traveling together. This can be easily discovered through the shared node.

Now say a business user doesn't just want to know who traveled with someone directly, but who is connected through a wider travel network: people who traveled with her, people who traveled with those people, and so on, up to a certain number of hops. In a graph database, going from "direct companions" to "companions up to six hops away" is a one-parameter change: you tell the query how deep to walk and it does the rest. Doing the same in SQL means a separate join for every extra hop (or recursive queries that are notoriously painful to write, read, and run), so we'll spare you the code this time.

So, while query depth quickly becomes a feasibility limit in table-based databases, in graph databases it's just a parameter and scales much better in terms of performance.

Performance comparison between relational and graph databases with increasing relationship depth. While relational databases (orange) degrade exponentially as hops increase, graph databases (blue) stay relatively flat regardless of depth. Source: Neo4j

This is also why tables quietly lose information that an operations expert treats as obvious. It's the gap we opened with: the table reports the five delayed flights, the graph explains them. If you know the root cause, you know how a delay at one hub propagates through aircraft rotations, crews, gates, and downstream connections, and which flights are about to fall next.

Tables report what happened. Graphs show what it's connected to, and what's coming next.

From graphs to graph AI

So far we've talked about storing and querying graphs. "Graph AI" is the umbrella for what you do on top of that structure, and it roughly comes in three levels:

• Ask the structure. Query the graph directly for patterns and paths, as in the example above. On its own, this already answers questions tables struggle with.
• Learn from the structure. Graph neural networks (GNNs) and graph embeddings let models learn from how nodes are connected, not just from their individual attributes. This powers link prediction (which connection is likely next?), node classification (is this account part of a fraud ring?), and anomaly detection.
• Reason over the structure. The web of relationships between concepts can become context for an LLM: instead of pulling isolated facts that happen to look similar to the question, it can follow how entities actually relate. It's closer to how people reason (in connections, not isolated facts), reaching for analogies to make sense of things. That's the idea behind GraphRAG, and it's a game changer for getting AI to reason over a knowledge base.

The common thread: in every case, the relationships are treated as signal, not as plumbing.

Where graph AI pays off for airlines

Three use cases, each led by the business problem rather than the technology.

• Fraud and loyalty abuse. The most widely recognized graph use case, and a useful credibility check: fraud rarely lives in a single transaction. It lives in patterns of connection across accounts, devices, addresses, payment methods, and loyalty redemptions. Look at one transaction and maybe it seems fine; look at the network and the fraud ring lights up.
• Delay and disruption propagation. The operations angle. In a network business, a single event rarely stays put: a delay, a grounded aircraft, or a late crew cascades through everything connected to it, because aircraft rotations, crews, and passengers are shared resources across flights. Modeling operations as a graph lets you ask which flights are most exposed to a disruption at a given hub, or which maintenance events create the most downstream risk. That's the difference between reporting delays and getting ahead of them.

How a single delay propagates through an airline network. Flight 123's delay puts its aircraft's next flight, its crew's following duty, and three downstream departures at the arrival hub at risk, plus passengers, baggage, and gate operations.

GraphRAG over operational knowledge. The trending one. If you've built a RAG system that keeps confidently hallucinating, part of the problem is that plain retrieval finds text that looks similar, not facts that are actually related. A knowledge graph gives the LLM structured, connected context, so it can reason over how entities relate instead of guessing. For an airline, think maintenance manuals, disruption playbooks, and regulations, where "related" means something very specific and getting it wrong is expensive.

Why aviation is a natural graph problem

This is where the conference insight landed. The leaders in the room were describing graph problems in plain operational language (crew scheduling conflicts, cascading delays, all kinds of dependencies) without the vocabulary to name them as such.

And structurally, it makes sense. An airline network is almost a textbook graph: airports are nodes, routes are edges, and crews and aircraft are constrained resources moving through that network under real-time pressure. Logistics and supply chains have the same shape. When your operation literally runs on a network, modeling it as a network stops being exotic. It's the natural choice.

The implication:

These aren't edge cases. If your business runs on connected operations, graph AI is worth understanding.

How to tell if you have a graph problem

Not everything is a graph problem, and pretending otherwise is exactly how good technology earns a bad reputation. So, a quick filter.

It's probably worth exploring graphs if: your data has entities that relate to each other in meaningful ways; consequences propagate across those relationships; your questions sound like "through what?" or "how many steps away?"; or your current models keep missing context that feels obvious to a human expert.

It's probably overkill if: your data is clean and tabular; your entities are essentially independent; and the business question is a straightforward lookup or a prediction on individual records.

The healthy starting point is the business question, not the technology. If the question is about networks, paths, or cascades, it's worth a conversation. If it isn't, a plain old table will serve you better, and we'll be the first to tell you so.

Where to go from here

The knowledge gap is real, and for once that's good news: it's an opportunity for the airlines that move first. The right opening question isn't "should we adopt graph AI?" It's "do we have problems where the relationships are part of the answer?" If the answer is yes, graphs are worth a serious look.

At Tryolabs we've built graph-based systems in production for exactly these kinds of problems, and a lot of that work starts by helping a team figure out whether they even have a graph problem in the first place. If something here resonated with what's on your own roadmap, that's a good conversation to have.