NEW: Scale AI Case Study — ~1,900 data requests per week across 4 business units Read now →

NEW: Scale AI Case Study — ~1,900 data requests per week across 4 business units Read now →

Denodo

Denodo is the original enterprise data virtualization platform. Founded in 1999, it predates the modern data stack by a decade and remains entrenched in large banks, insurers, and pharma companies that need to query across dozens of legacy systems without moving data.

Denodo is a data virtualization platform. The basic idea is the same one Trino and Dremio implement — query data wherever it lives, don't move it — but Denodo has been doing it since 1999, almost a decade before the term "data lake" existed and two decades before the modern open-source query engines arrived. It is the enterprise legacy player in the data virtualization space, and it is still doing extremely well in the kinds of organizations that have hundreds of source systems, decades of accumulated technology debt, and a deep aversion to bulk-copying customer data into a public cloud warehouse.

Think of Denodo this way: if Trino is the modern federation engine for engineers, Denodo is the federation platform for the enterprise architecture committee. They share an idea but they live in different worlds.

Origin Story

Denodo was founded in 1999 in A Coruña, Spain, as a spin-off from research at the Universidade da Coruña. The original problem was screen-scraping and integrating data from heterogeneous web and enterprise sources — the late-90s version of "all our data is in different systems and we need to query it together." The company grew quietly, moved its headquarters to Palo Alto, and built deep relationships with large enterprises in financial services, pharma, telecom, and government.

By the time the modern data stack arrived, Denodo had a 15-year head start in features like cost-based query optimization across federated sources, fine-grained row and column security, business glossaries, data lineage, and integration with legacy systems most open-source engines have never touched (mainframe DB2, SAP, Salesforce, web services, even SOAP APIs). It was never trendy and it was never cheap, but in regulated industries it was — and is — the safe enterprise choice.

What Denodo Actually Does

Denodo's product is a layered platform, not just a query engine. The components, in roughly the order a customer encounters them:

1. Connectors. Out of the box, Denodo has 200+ connectors — to relational databases, cloud warehouses, SaaS systems, web services, mainframe sources, message queues, NoSQL databases, even spreadsheets. The breadth here is genuinely larger than any open-source alternative.

2. Virtual data model. Customers define "base views" (one per source table) and then layer "derived views" on top — joins, aggregations, business logic. The result is a logical data model that looks like a single database to anyone consuming it, but actually pulls from dozens of systems behind the scenes. This is essentially a semantic layer baked into the query engine.

3. Cost-based optimizer. When a query hits a derived view, Denodo's optimizer figures out which sources to push down to, how to do joins, when to cache, when to materialize. For complex federated queries this is genuinely hard — the optimizer has to model network costs, source capabilities, and partial pushdown — and Denodo has had two decades to refine theirs.

4. Data services layer. Denodo can expose its virtual views as REST APIs, OData services, GraphQL endpoints, and JDBC/ODBC. The "data as a service" pitch — where the virtualization layer feeds applications, not just analysts — is an important part of how Denodo gets bought.

5. Governance, security, lineage. Row-level and column-level security, masking, audit trails, business glossary integration, lineage across federated sources. This is the stuff enterprise architects in regulated industries care a lot about and which open-source query engines often handle weakly.

Where Denodo Wins

The Denodo customer profile is consistent and easy to describe. It's a large, regulated enterprise — a global bank, a global insurer, a top-20 pharma company, a national telecom — with the following properties:

  • Hundreds of source systems, including some mainframe and legacy ERP that no modern tool understands.
  • Strong regulatory or sovereignty constraints that make moving data into a cloud warehouse politically or legally difficult.
  • A central "data office" or "data fabric" initiative tasked with making data accessible across the organization without forcing every team to move to a new platform.
  • Existing relationships with traditional enterprise software vendors and a procurement process that prefers a single throat to choke.

In that profile, Denodo is genuinely a strong fit. The breadth of connectors, the maturity of the optimizer, the security model, and the vendor relationship matter more than any benchmark.

Where Denodo Struggles

Denodo struggles in the modern data stack as it is being built today by smaller, more cloud-native organizations. The reasons are roughly:

It is expensive. Denodo is sold on a traditional enterprise license model, and the prices are in the same neighborhood as other enterprise infrastructure software. For a startup or mid-market team, the cost is hard to justify when Trino is free.

Performance on lake workloads. Denodo's heritage is virtualization across operational sources. It does support querying Parquet and cloud storage, but its performance on petabyte-scale analytical lake workloads is generally not in the same league as Trino, Dremio, or a modern warehouse. If your dominant use case is "fast SQL on a giant Iceberg table," Denodo is not the obvious tool.

It is not the cool kid. Denodo does not have the developer mindshare or open-source community that Trino, DuckDB, or Dremio have. Engineers joining a Denodo team often haven't heard of it before. This matters less in the enterprises Denodo serves, but it matters a lot in the broader data ecosystem narrative.

The category itself is being absorbed. "Data virtualization" as a standalone product category is under pressure from two sides. Modern query engines (Trino, Dremio) do federation as a feature. Modern warehouses (Snowflake, BigQuery, Databricks) do federation through Iceberg, BigLake, and Lakehouse Federation. The independent virtualization vendor has to keep arguing why an enterprise should pay for a separate layer instead of using what their cloud platform already includes.

The Honest Market Take

Denodo is a successful, profitable, deeply-entrenched enterprise vendor that the modern data stack discourse largely ignores. It will keep winning the customers it has been winning for 25 years — big regulated enterprises with complex legacy estates — and it will keep losing the customers that grew up cloud-native. Both of those things will be true for a long time.

The interesting question for Denodo is whether it can credibly reposition itself around "data fabric" and AI-ready governed data products in a way that brings new buyers in, or whether it stays a stable but slow-growing enterprise software business. That's a strategy question, not a technology question.

TextQL Fit

TextQL connects to Denodo via JDBC. For organizations that have invested in a Denodo virtual data model — meaning they've already spent the effort to define base views, derived views, business glossaries, and security — pointing Ana at Denodo is a particularly clean integration. The semantic and security context that the Denodo data architects have built becomes the grounding context for the LLM, which is exactly the situation in which natural language analytics works best: when there's a curated layer between the user and the raw data.

See TextQL in action

See TextQL in action

Denodo
Founded 1999
Headquarters Palo Alto, CA (founded in A Coruña, Spain)
Founders Ángel Viña and academic team from Universidade da Coruña
License Commercial (proprietary)
Category Query Engines / Data Virtualization
Typical buyers Banks, insurers, pharma, telecom, government
Monthly mindshare ~30K · enterprise data virtualization; legacy customer base; large per-seat deployments