An analyst gets a question on a Tuesday afternoon. Which of our enterprise accounts opened support tickets in the last month, and what did they spend with us last quarter?
The answer exists. It has always existed, but it’s not all in the same place. The tickets are in one system, the spend is in a data warehouse, and the account hierarchy is in a PostgreSQL database behind the CRM. Three sources, all accessible, all containing exactly the data required. And yet answering the question takes two weeks, because before anyone can write the query, someone has to build a pipeline to bring all three into the same place.
SQL on anything removes that waiting period. The data does not move. Instead, the question gets asked by accessing data sources without centralization. This is the data architectural pattern built on data federation, powered by a compute engine like Trino, and it works whether your data sits in a lake, a warehouse, a lakehouse, a streaming system, or a SaaS application.
Let’s dive in.
Key takeaways
- SQL on anything is not a new query language. It uses the standard SQL you already know, running against sources that stay exactly where they are.
- Connectors determine which data sources you can reach, spanning databases, data warehouses, data lakes, streaming systems, and SaaS applications.
- Centralizing everything into one store creates lock-in through proprietary formats, bundled pricing, and accumulated tooling. Federation preserves the option to change any one component later.
- Querying in place does not mean that you never copy data. You can still centralize when it makes sense, and that choice is still yours. What you avoid is copying everything upfront just to answer a question.
- Starburst Galaxy and Starburst Enterprise are the two ways to implement this using Trino.
What does SQL on anything mean?
SQL on anything refers to a single SQL query that spans different systems. You write one statement, it reaches several sources, and none of those sources have to be staged in a data warehouse beforehand.
The SQL itself is standard SQL. SELECT, JOIN, WHERE, and GROUP BY all behave exactly as they always have, and your query does not care whether a catalog resolves to PostgreSQL, to an Iceberg data lakehouse on Amazon S3, or to a data warehouse. Underneath, the compute engine plans the statement, asks each connector for its slice of the data, and combines the results before returning them.
Connectors define which data sources you can reach
Each connector maps one data source into tables, columns, and rows, which is what allows standard SQL to read from it. Different data sources can be accessed using different connectors.
Starburst supports more than 50 connectors extending access to data lakes, data warehouses, streaming systems, relational databases, and SaaS applications. For example, when accessing a data lakehouse, a single query can read across Hive, Iceberg, Delta Lake, and Hudi tables, so mixed table formats do not need consolidating before you can join them. Operational databases and warehouses work the same way, as does any other source once a connector exists for it.
Why universal data access matters for analytics and AI
Most analytics work begins with a question that spans more than one system. Building a dashboard, packaging a curated data product around the underlying datasets, or grounding an AI agent all start from the same assumption, which is that the data can be reached. In most organizations that assumption requires a project behind it, and the result is a long tail of questions that never get asked because answering them would mean joining the pipeline backlog.
Getting past data centralization
All of this points to the need to move beyond data centralization. When your architecture assumes every data source must eventually land in one store, that store begins dictating decisions well beyond where the data sits. You migrate toward it, you standardize on the formats it prefers, and you accept its pricing model as a fixed cost of asking questions.
Federation inverts the relationship. Data stays in whichever source genuinely suits it, whether that is object storage for scale, an operational database for latency, or a warehouse a business unit already depends on, and the query layer adapts to those choices rather than overriding them. This preserves optionality, meaning you keep the ability to change any one component later without re-architecting everything around it.
That flexibility matters most in the situations that have become ordinary rather than exceptional:
- Hybrid deployments, where some data must remain on-premises while analytics runs in the cloud.
- Post-acquisition estates, where an acquired company arrives with its own warehouse, formats, and conventions, and a full migration would take years.
- Data sovereignty requirements, where regulation keeps certain records inside a specific region and migration is not legally available as an option.
In each of these cases, centralizing first is expensive, slow, or prohibited outright. Federation is what makes the estate queryable without waiting for a migration that may never be justified.
AI raises the stakes on access
A model can write syntactically correct SQL and still return a wrong number, because the business context it needed lived in a source it could not query. This is a common way enterprise AI projects stall, and it is an access problem rather than a model problem.
That context is rarely consolidated in one place. Fiscal calendar definitions may live in a finance system, customer hierarchy in a CRM, and transaction detail in a lakehouse. An agent reasoning across all three needs access to all three, not to a subset that happened to be convenient to centralize.
Access without governance is a liability
Being able to query everything is only useful if you can also control who queries what. Those controls have to be enforced at the engine rather than separately at each source, because a policy applied in three systems and missed in the fourth is not a policy.
In practice this means row filters restricting which records a given role can see, column masks hiding sensitive fields such as salary or account numbers while leaving the rest of the table usable, and role-based or attribute-based access control applied consistently across every catalog the engine can reach. A semantic layer sits alongside these, defining shared meaning so two teams querying the same source arrive at the same numbers.
There is a point here that runs against intuition. Federation is often assumed to weaken governance, on the grounds that reaching more sources means more exposure. In practice the opposite tends to hold, because the governance problem in most organizations is not reach but duplication. Every pipeline built to make a source reachable produces a copy, and every copy is a new surface that needs its own permissions, its own masking rules, and its own review when a regulation changes. A customer table replicated into three environments is three places where someone can be granted access by mistake.
Querying in place removes those intermediate copies, which means fewer places to secure rather than more. It also gives you a single point where access is recorded. When every query runs through one engine, the audit trail covers all of it, and questions like who read this table last quarter have an answer that does not require assembling logs from four systems with four different formats.
The sequencing matters as much as the controls. Governance retrofitted after teams have grown accustomed to broad access is a political problem rather than a technical one, because you are taking something away rather than defining it up front. This is why access and governance have to advance together rather than sequentially.
Federation gets the query to the data. It does not define what your business means by revenue, which customer table is authoritative, or who is permitted to see either. Those remain decisions your organization has to make, and the engine’s job is to enforce them consistently once you have.
When you should still centralize data
Federation does not make centralizing obsolete. What it changes is the status of the decision, turning consolidation from a prerequisite into a choice you make for a specific workload. The useful question stops being whether to centralize and becomes which subset genuinely warrants it.
These often include:
- A governed persistent table that multiple teams depend on and that should not change without review.
- A dashboard with an SLA behind it, where query latency against a slow operational source is not acceptable.
- Training data that must stay fixed while a model is developed and evaluated.
- Historical facts accumulating over years, which belong in a data lakehouse table rather than being repeatedly pulled from an operational system.
What these share is a workload that benefits from a stable, governed copy. Everything outside that set can be queried where it already lives, which is the difference between centralizing deliberately and centralizing by default.
Getting started with SQL on anything
How do you begin? Start with a question your organization has postponed because it spans two systems. Most teams have several of these. Connect both sources as catalogs and write the join, which will usually take less time than scoping the pipeline that was going to answer it.
Audit your connector coverage against the sources that matter most. Where a connector exists, federation replaces integration work immediately. Where one does not, you know which sources still require copying and can plan accordingly.
Finally, put the governance layer in place before you need it rather than after. Access control, views, and shared definitions are what keep broad query access from becoming a liability as usage grows across teams.
Want to see it in practice? Check out Starburst Galaxy and connect your first two sources.
FAQs
Is SQL on anything the same as data federation?
Federation is the mechanism that executes a query across sources without copying them into one repository. SQL on anything describes the resulting capability, which is one SQL dialect reaching across all of those sources.
Which data sources can I query?
Any source with a connector that maps it to tables, columns, and rows. Starburst supports more than 50 connectors across data lakes, data warehouses, streaming systems, relational databases, and SaaS applications. What matters as much as coverage is connector depth, since a connector that supports pushdown lets the source do the filtering while a shallow one pulls raw data into the engine. Where no connector exists yet, you are back to copying data or building a custom plugin.
Do I still need a data warehouse?
You may still run one, and plenty of organizations should. What changes is that you no longer have to copy every other source into it before you can join across them. The warehouse becomes one participant in a federated architecture rather than the mandatory destination for all data, which also means you are no longer paying to store copies of data whose system of record lives elsewhere.
How does this stay governed?
Virtualization, access control, and catalog policy have to travel with the query rather than being enforced separately at each source. That means row filters, column masks, and role-based or attribute-based access control applied consistently across every catalog the engine can reach.
What is the difference between Galaxy and Enterprise?
Starburst Galaxy is built for cloud workloads, and is the easiest way to operate data federation using SQL the cloud. Starburst Enterprise is self-managed, and should be chosen when data has to remain inside a private, hybrid, or on-premises environment. Both implement federated SQL on Trino and both give you the same SQL interface, so the choice comes down to who runs the infrastructure and what your data residency requirements are.
Does SQL on anything mean I never copy data?
No. You copy a subset when you need persistence, a stable dashboard grain, or training data that must not shift underneath you, and those are legitimate architectural decisions. What changes is that copying becomes a choice you make for a specific reason rather than a prerequisite you complete before anyone in the organization is able to ask a question.
