Great in theory, but...
Query federation is an idea as old as databases themselves. It is as seductive as it is simple: instead of moving the data to the query engine, you query the data "where it lives."
In theory, this increases data access, saves cost, and simplifies your data architecture.
In practice, it rarely works out this way. Let's dig into why.
During POCs and demos, federation works beautifully. These are small-scale, controlled environments where the technology shines. However, as you move from POC to production, there are three issues users regularly run into:
- Performance: Queries are slow and inconsistent. Timeouts happen regularly, and multiple users are unable to query in parallel.
- Cost: Spend on data transfer, source system compute, and the federation engine itself grows far beyond what was budgeted.
- Maintainability: A never-ending stream of correctness bugs, data quality issues, and performance bottlenecks keeps teams permanently in debug mode.
Let's dig in.
Performance
There are three ways to make search fast and scalable: indexing, caching, and parallel processing. Federated search does not support any of the three properly.
Indexing
You can't index data if you don't read it and have the ability to access it granularly. This might be obvious to most readers, but it's worth stating explicitly: you can't index a third-party data store or vendor API without reading and storing all the data. This means the only systems you can index are file systems or object stores, and only after you've read them.
At this point, you're describing a data platform, not a federated system, because you're paying the cost of moving and reading the data during indexing.
Caching
You can't cache a federated system effectively, because you don't know when to invalidate the cache. Security logs regularly get late-arriving events. If those arrive in a third-party system, you have no way of knowing your cache is invalid. Moreover, caching assumes everyone is hitting the same data regularly.
In security operations, most investigations cover new scope. It's rare that you'll reinvestigate the same environments and time periods repeatedly. As a result, your cache hit rate will be very low unless you actively pre-populate the cache, which, again, makes this a data platform and not a federated system.
Parallel processing
You're bottlenecked by the capacity of the source. Vendor APIs and third-party data stores are not built for massive parallel processing. Nor do your vendors want to pay the compute bill for your large, concurrent queries against their API.
As a result, you'll get throttled.
When you combine this with the inability to cache and index, you get a "lethal trifecta" of poor query performance: you have to scan all the data because you don't have an index, read from a third-party system because you don't have a cache, and read in serial because you can't process the data in parallel.
If your vendor claims their federated search is fast at scale, run a load test: multiple concurrent needle-in-a-haystack queries over long time periods, against the same third-party APIs. Don't fall for a pretty demo, or believe that a small-scale POC is representative of a production workload.
Federation performs well during demos, but fails at scale.
Cost
Federation is often pitched as a cost saver, but it rarely works out like that in practice. Cost overruns are frequent for two reasons.
Unanticipated data movement
Even when you query data "where it lives," you have to move the results back to where you're querying from (obviously). If you're not able to push the filter down into the source data store, you have to pull all the data for the time period you're searching over.
This happens more often than you think!
Searches for string patterns, IOCs, actor aliases, or other subsets of the data require an indexed data store (i.e., a SIEM). Against object stores or vendor APIs, you'll have to pull all the data.
And this happens every time you query. If the data resides in a separate region or cloud, you pay the full egress charges every time. You can easily rack up thousands of dollars in transfer costs for a single, ill-formed query against a large table residing in a different cloud.
Now combine that with agentic querying, and it's not hard to imagine how the bill grows: you ask the agent to answer a simple question, it decides to pull the last three months of data from another cloud, and the rest is (billing) history.
Duplicate compute cost
When you're federating, you're paying for compute twice: once at the source system, and again for the federation engine. Moreover, since neither engine gets to fully optimize the query, execution is often far less efficient than if the query had run directly against the source1.
Even if the source doesn't charge for queries directly (e.g., your EDR or a security vendor's API), the vendor bears the cost of the compute you're using, and will rate limit or throttle you if you issue a large volume of inefficient queries (which federated systems regularly do).
This might seem like a theoretical concern at the POC stage, but it becomes very real once you hit AI scale. Not only are you paying for duplicate hardware, you're also paying two vendors' margins (often a 6-10x markup over the compute). Combine that with the inefficiency mentioned above, and you can quickly get to >10x the cost of doing the same work in a single system.
Maintainability
Maintainability is the most important feature you've never heard of. Since federated systems don't own the data or the query execution layer, it's a lot harder to manage edge cases proactively. This makes the system harder to debug and maintain, both for vendors and end users.
Here are some issues federated systems regularly wrestle with.
Correctness
What happens if you query three sources, and only two return data? What happens if the schema of an upstream source changes? What happens if you get malformed data (e.g., a timestamp in the wrong format)? Since federated systems don't own the data layer, it's far harder to assert what the correct results are, or to retry after partial failures.
As a result, federated systems must be either overly conservative (i.e., fail your query if there is any chance that the results are incorrect) or overly aggressive (i.e., present results that might be wrong). Neither is a good place to be.
Observability
Databases usually expose unified telemetry to help debug performance issues end to end. Federated systems can't offer any of that for the source systems they query. As a result, performance, data quality, and correctness issues must be detected and debugged across multiple systems, which is about as fun and productive as it sounds.
Moreover, any improvement or fix you'd like to make requires coordinating changes across the source systems and the federation engine, which is not trivial. Worse, source systems often don't expose the knobs required to optimize for the federation engine, since they're designed to meet different objectives (e.g., limiting compute load and maintaining stability instead of maximizing throughput). So even if you find the problems, fixing them is usually painful and complex, or outright impossible.
So what's the alternative?
If federation is a bad idea (which it almost always is), what should you do?
Centralize the data on a Modern SIEM.
Your queries will be faster, and your platform will be easier to maintain. It's often similar in cost, or even cheaper, and far more predictable.
Most importantly, it lets you start using the data more.
One of our most consistent observations from building data solutions is that once data is available, people start using it. In security, this means hunts, detections, investigations, and reporting. Don't close that door by building your business case on the hope that people won't query their federated data much.
Federation is a great idea in theory. Unfortunately, it rarely delivers as promised.
Buyer beware.
FAQ
Are there any cases when federation is the right approach?
Absolutely! Federation can work well when the following is true:
- The source is small.
- You're querying it infrequently.
- The source is rewritten frequently.
- The source is the right long-term storage solution for that specific data.
For example, if you're running a SOAR or AI SOC that needs to collect small, specific datasets from different systems during an investigation, federation is likely an acceptable approach, particularly if these are operational data stores whose values change frequently, which makes replicating them accurately challenging.
Similarly, if you need to run the occasional threat hunt across EDR and cloud data (and that data is already ingested into your EDR and CDR respectively), federation will work well.
However, the moment you're reading all the data from a large source (e.g., because you're detecting, hunting, or building baselines against it), or you're searching large volumes over long time periods, problems will come knocking.
Why should you trust us about federation?
Trino, the query engine we built, is famous for its federation capabilities.
And at our former company, Starburst Data, we supported federation use cases for many of our largest customers. So we know better than most where it works and where it breaks.
But you don't need to take this on faith.
If you're considering a federation vendor, run a proper load test with realistic, demanding queries: searches over long time periods, multiple concurrent queries, joins across sources, and so on. And make sure you verify your TCO analysis across multiple usage scenarios, taking into account that demand often builds over time once data becomes available.
Footnotes
-
There are many examples where this happens. Among the most common is the following: Federated queries usually rely on joining data from two sources together, such as finding all the endpoint activity (from your EDR) for your admins (from the IdP). Data warehouses are built to optimize these queries, thereby saving compute costs and reducing query time. A federation system, on the other hand, can't push down the filters from one source to another, thereby forcing you to read far more data than necessary. ↩
