Introduction
When Denodo released Platform 9 in June 2024, the company described it as a release developed over several years — and the scope of the changes reflects that. Platform 9.0 is not an incremental update. It marks a deliberate architectural shift: from a mature data virtualization engine toward what Denodo calls a “logical data management” platform, with artificial intelligence woven into both the user experience and the underlying data delivery layer.
For enterprises already running Denodo 8.0, the 9.0 release introduces meaningful functional improvements alongside real infrastructure changes — a new runtime (Java 17, Tomcat 10.x), a new versioning scheme, and a series of AI capabilities that change how both technical and non-technical users interact with data. For teams evaluating Denodo for the first time, Platform 9 represents the baseline from which all current development is building — through 9.1, 9.2, and 9.3 in the months that followed.
This post breaks down what is actually new in Denodo Platform 9.0, what changed under the hood, and how those changes translate into practical benefits for data teams and the business stakeholders they serve.
What Denodo Platform 9.0 Actually Changed
The Versioning Shift — and Why It Matters
Before getting into features, the versioning change in Platform 9 is worth understanding because it affects how teams plan upgrades going forward. In previous releases, Denodo used date-based update identifiers (e.g., 8.0u20240306). Platform 9 switches to a sequential numbering model: 9.0 is the base release, 9.1 is the first update, 9.2 the second, and so on. This is a cleaner model that makes release cadence more predictable for enterprise teams managing upgrade cycles.
The infrastructure baseline also changed significantly. Platform 9.0 ships with Java 17 (versus Java 11 in Denodo 8.0), Apache Tomcat 10.x (versus Tomcat 9.x), and doubles the default JVM heap allocation from 1 GB to 2 GB. The JMS API was upgraded to Jakarta Messaging API, which has a direct compatibility implication for teams using JMS connectors built on the older Javax JMS API — for example, the ActiveMQ 5.x connector must be replaced with the ActiveMQ 6.x connector in 9.0 environments.
Support for Red Hat Enterprise Linux 9.0 was also added, and the ODBC data source feature — deprecated since 8.0 — is now disabled by default. These are not cosmetic changes. They signal a platform that has moved to a modern, supported infrastructure baseline, which matters for long-term supportability and security posture.
AI-Native Query Support: Eliminating the SQL Requirement
The most visible capability added in Platform 9.0 is the Denodo Assistant’s natural language query support, which allows business users to query enterprise data without writing SQL. Users type their question in plain English and receive not just the result but a breakdown of how the query was constructed — making the experience both productive and transparent.
This capability integrates with third-party large language models through standard REST APIs. Denodo does not bundle its own LLM. Instead, Platform 9.0 supports connecting to models hosted in services like OpenAI and Amazon Bedrock. Administrators configure the LLM endpoint and credentials via the Design Studio’s Denodo Assistant settings. The assistant then uses the metadata from the virtual views — column names, descriptions, tags — to formulate SQL queries that match the user’s intent.
This matters practically because it shifts who can interact with the data layer directly. In traditional Denodo implementations, self-service analytics required analysts who were comfortable writing VQL or SQL against the virtual views. With 9.0’s natural language layer, business users who understand the business question but not the data model can get answers without routing a request through a data team.
One design constraint worth noting: the LLM receives view metadata (column names, descriptions) when constructing queries. If views are poorly documented — no descriptions, no business-aligned naming — the quality of natural language results degrades. This reinforces the importance of investing in the semantic layer before rolling out AI-assisted query features to end users.
RAG Support: Making Denodo the Data Layer for Generative AI
Platform 9.0 introduced formal support for retrieval-augmented generation (RAG), positioning Denodo as the data supply layer for enterprise generative AI applications. The premise is straightforward: LLMs trained on static data are unreliable for questions that depend on current enterprise information — inventory, customer records, pricing, regulatory filings. RAG addresses this by pulling live, governed data from enterprise sources at query time and providing it as context to the model.
Denodo’s implementation allows enterprises to route live, real-time data from across their distributed data landscape into their generative AI pipelines — without copying that data into a separate store for the AI to access. The governed access policies at the Denodo layer remain in force: a RAG pipeline operating through Denodo will only surface data that the calling user or service account is authorized to access.
This is a meaningful advantage over unmanaged RAG architectures. In many early generative AI implementations, teams connect LLMs directly to databases or unstructured data stores with minimal governance, creating regulatory exposure and inconsistent results. Denodo’s virtual layer applies masking, row-level security, and classification policies before data is passed to the model — making RAG outputs more trustworthy and auditable.
New Data-Preparation Wizards: Self-Service Without Engineering Dependency
Platform 9.0 added a set of self-service data preparation wizards that allow users to customize data products without requiring support from data engineering teams. These wizards enable modifications like adding derived columns, applying filters, renaming fields, and joining data from multiple views — all through a guided UI rather than code.
In practice, this collapses a category of requests that would previously have required a formal ticket to the data team. An analyst who needs a modified view of an existing dataset — filtered to a specific region, enriched with a calculated field — can create that view themselves through the wizard and work with it immediately. The resulting modifications are still governed by the platform’s security model, so the self-service capability does not create uncontrolled data sprawl.
This capability builds directly on Denodo’s semantic layer. Because the underlying virtual views carry business context (descriptions, ownership, classifications), the preparation wizards can surface meaningful field names and relationships rather than exposing raw database column identifiers. Teams that have invested in building a well-documented semantic layer in Denodo 8.x will see the most immediate benefit from the 9.0 preparation tools.
Enhanced MPP-Based Data Lake Engine
Platform 9.0 extended the massively parallel processing (MPP) engine with simplified configuration and improved integration with open table formats — specifically Apache Delta and Apache Iceberg tables. This reduces the friction of connecting Denodo to modern data lakehouse environments and makes it straightforward to use those environments as both a source for virtualized queries and as an acceleration layer for heavy analytical workloads.
The MPP engine in Denodo handles query scenarios where federation alone is insufficient — cross-source analytical queries that benefit from parallel execution across large data volumes. With 9.0’s Iceberg support, the MPP engine can cache virtual view data in Iceberg format, enabling analytical queries to run against materialized Iceberg snapshots with lakehouse-native performance characteristics while still benefiting from Denodo’s governance and semantic layer.
For organizations that have adopted Microsoft Fabric’s OneLake, Snowflake, or Databricks as their analytics backbone, this improvement makes Denodo a more natural complement rather than a separate data integration silo. Denodo can federate across those platforms, apply governance, and push computation into the native MPP engine of the target system — reducing data movement and egress cost.
Enhanced Data Inspection and Governance Tooling
The compliance and governance capabilities in Platform 9.0 received targeted improvements, specifically around auditing and inspection of data-access policies. The enhanced inspection tools give administrators better visibility into how access policies are being applied across the virtual layer — which users and roles have access to which views, what masking rules are active, and where policy gaps may exist.
This addresses a real operational challenge in large Denodo deployments: as the number of virtual views and data consumers grows, maintaining a clear picture of effective access across the catalog becomes difficult. The 9.0 inspection tools are designed to make that audit process more systematic, supporting compliance workflows under GDPR, HIPAA, CCPA, and equivalent regulations.
The Version Control System integration also gained a meaningful improvement: a new wizard to resolve conflicts in unresolved VCS elements, replacing the previous behavior where a failed pull would simply abort. This, combined with new support for versioning users, roles, privileges, and Global Security Policies, makes the platform significantly more practical for teams running Denodo in CI/CD-style development workflows — an approach common in organizations that manage virtual data models with the same rigor as application code.
Why Platform 9.0 Matters Beyond the Feature List
The individual features in Denodo 9.0 are worth understanding on their own. But the more significant shift is architectural intent. Denodo is moving the platform’s center of gravity from data virtualization — a technique — toward logical data management — a broader data strategy.
In practical terms, this means Denodo 9.0 is designed to serve not just traditional BI consumers (analysts and report developers writing SQL) but a wider audience: business users who need self-service access, AI engineers who need governed real-time data for model inputs, and operations teams who need a single point of enforcement for data policy across a diverse cloud and on-premises landscape.
TDWI Vice President and Senior Research Director Fern Halper, commenting at the 9.0 launch, noted that Platform 9.0 “promises strong support for a data fabric that can accommodate both physical and logical data architectures, with enhanced AI capabilities to improve the data fabric’s flexibility in supporting a wider variety of different user personas.” That framing captures the release’s intent: to handle a broader range of data consumers, not just a deeper one.
For teams running Denodo in combination with Microsoft Azure, Power BI, or Microsoft Fabric, the 9.0 release strengthens the case for using Denodo as the federation and governance layer above the entire Azure data stack. The RAG support, natural language querying, and semantic layer capabilities connect directly to the kind of AI-augmented analytics workflows that Microsoft’s Copilot and Azure OpenAI integrations are designed to power.
Prism Analytics, working with clients across the Microsoft data ecosystem, has seen this dynamic play out in Denodo implementations where the 9.x platform capabilities unlock use cases that 8.0-era deployments simply could not support — particularly around governed self-service and generative AI data supply.
What to Know Before Upgrading from Denodo 8.0 to 9.0
Upgrading from Denodo 8.0 to Platform 9.0 requires more planning than a typical update cycle, given the infrastructure changes involved.
Java and container compatibility. The shift from Java 11 to Java 17 and Tomcat 9.x to Tomcat 10.x means custom extensions, third-party connectors, and any JMS-based integrations need to be validated against the new runtime before migration. The Jakarta JMS API change is particularly relevant for teams using ActiveMQ, IBM MQ, or similar messaging infrastructure.
JDBC driver updates. Several JDBC drivers are no longer distributed in Platform 9, including the older Amazon Redshift driver (v1.x), the Databricks driver v1, and the Oracle 12c driver v12.2.0.1. Teams with live connections to these systems need updated drivers in place before upgrading.
ODBC sources. If your Denodo 8.0 environment includes ODBC data sources (already deprecated in 8.0), these will need to be migrated to JDBC equivalents before the 9.0 upgrade, as ODBC creation is disabled by default in 9.0.
VCS element resolution. The new conflict resolution wizard in 9.0 is an improvement, but if your team carries unresolved VCS elements forward from 8.0, those will need to be resolved as part of the migration. Denodo’s community documentation on upgrading to Platform 9 provides a checklist that is worth working through methodically.
LLM configuration. If you intend to enable Denodo Assistant’s natural language features post-upgrade, the AI capabilities require the Enterprise Plus subscription bundle and a configured LLM API endpoint. Plan for this setup as part of the upgrade project rather than as a post-go-live addition.
Conclusion
Denodo Platform 9.0 is the foundation of a major generational shift in how the platform delivers data. The AI-native query support and RAG capabilities extend Denodo’s reach to audiences — business users and AI engineers — who were not practical consumers of earlier platform versions. The MPP and open table format improvements deepen its role in modern lakehouse architectures. And the governance and inspection enhancements give administrators the audit confidence needed for regulated data environments.
For teams on Denodo 8.0, the upgrade case is strong — but the infrastructure changes mean the migration needs proper planning, not just a version bump. For teams new to Denodo, Platform 9.0 (and its subsequent updates through 9.3) represents a meaningfully different kind of data platform than its predecessors.
Prism Analytics partners with enterprises across the Microsoft data ecosystem — from Denodo data virtualization implementations to Microsoft Fabric development and legacy BI migration. If you’re evaluating or upgrading Denodo, contact us to discuss your architecture and timeline.