When a vendor is acquired, the software doesn’t change on the day the deal closes – and SAP’s purchase of Dremio, completed in July 2026, is no different. What changes is slower and further-reaching: who sets the roadmap, and how easily you could leave if that roadmap stops suiting you. For a lakehouse built on Apache Iceberg®, the leaving part is more reassuring than most teams expect, because the engine is the one piece you can replace without moving your data. This guide covers what a move to Trino involves – and what doesn’t need to move at all.
TL;DR
- Dremio keeps its tables in Apache Iceberg, an open and engine-independent format. Swapping query engines is therefore mostly a catalog operation: the data files in your object storage never move – a new engine is simply told where they already are.
- Trino can point its catalog at those existing Iceberg tables and query them in place. The hands-on work is everything Dremio layers on top: its views and semantic layer, its Reflections acceleration, access policies, and any live database connections. Those you rebuild.
- Run it as a gradual, table-by-table change alongside Dremio, piloting on copies first – not as a weekend big-bang.
- Trino keeps the whole stack open and inside your own infrastructure. For regulated setups, one detail is worth logging: per Dremio’s own docs, its Enterprise-on-Kubernetes build has, since v26.0, sent operational metrics to a Dremio endpoint by default (switchable off by contract).
Do you actually need to move off Dremio?
Quick answer: often, no. If your organisation’s centre of gravity is already SAP and Business Data Cloud is on the roadmap, Dremio moving inside SAP can be convenient rather than concerning – the engine ends up alongside the finance and supply-chain data it reads. An acquisition isn’t a cue to tear anything out. It is a cue to revisit one assumption: if part of why you chose Dremio was that it was an independent, open-format specialist rather than a slice of a large platform vendor, that is what shifted in July – the ownership, not the code. Whether it changes your plans is a procurement question for your next renewal, and the answer is specific to you.
Why an open format turns this into an engine swap
A move off Dremio can be low-drama because of where the data sits. Dremio writes its tables as Apache Iceberg – an open specification, not a Dremio-only format – so the Parquet™ data and the Iceberg metadata live in object storage you already control, and any Iceberg-aware engine can open them without a conversion step. Nothing has to be re-ingested or duplicated for a different engine to read it.
What actually ties a set of tables to one engine isn’t the data; it’s the catalog – the index of which tables exist and which metadata file is current for each. Dremio’s catalog is built on Apache Polaris™, an Iceberg REST catalog. Trino’s Iceberg connector works with several catalog types – Hive™ Metastore, AWS Glue, a JDBC catalog, Nessie, or an Iceberg REST catalog – so the task in front of you is registering tables in the catalog you pick, not shuttling terabytes between systems.
What comes with you, and what you rebuild
The data is the easy part. A clean switch means accounting for everything Dremio built on top of it:
- Tables (Iceberg): stay exactly where they are. You register them in the new catalog and not a single byte is copied.
- The catalog: pick one of Trino’s supported catalog types and register the tables there. In practice this is where most of the effort lives.
- Views and the semantic layer: Dremio’s virtual datasets are SQL, but in Dremio’s dialect. Plain SQL moves across intact; Dremio-specific functions want checking. You re-express them as Trino views or as dbt models – and note that whether Trino persists Iceberg views depends on the catalog type (Hive Metastore and others do; the REST catalog does not).
- Reflections (acceleration): these, and the automatic query-rewriting that picks them, are Dremio-only – there is no drop-in replacement. Instead you reproduce the speed on purpose: materialised or pre-aggregated tables behind your busiest dashboards, partitioning and sort order that follow how people filter, and scheduled compaction. Plan to measure the result rather than assume it matches.
- Access policies: row and column rules and role mappings are re-expressed in the target’s model – with Trino, through Open Policy Agent (OPA) – and checked against your identity provider with real users before anyone relies on them. This is the step where a slip exposes data, so test it deliberately.
- Live connections: anything you query straight through Dremio becomes a Trino catalog in its own right; Trino federates across more than thirty source types (PostgreSQL, MySQL and others). Per connection, choose between reading it in place and bringing it into Iceberg.
Making the switch with Trino
There’s no need to move everything at once, and good reason not to. Keep Dremio running, bring workloads across a table at a time, and respect one rule: any given live table should be managed by exactly one catalog. If two catalogs point at the same table, each keeps its own idea of the table’s current state, so a change on one side is invisible to the other – and Dremio’s routine snapshot cleanup can remove files the other catalog is still relying on. Pilot on throwaway copies, never the live tables.
Registering an existing Iceberg table in Trino looks like this:
-- Registering copies no data; it only tells the new
-- catalog where the existing Iceberg metadata lives.
CALL iceberg.system.register_table(
schema_name => 'analytics',
table_name => 'web_events',
table_location => 's3://warehouse/analytics/web_events'
);Switch the procedure on with iceberg.register-table-procedure.enabled=true, and pin an exact metadata file with the optional metadata_file_name argument if you need to. When you move a table for real, the sequence is short: quiesce it in Dremio (stop writes and any maintenance), register its current metadata in Trino, move the pipelines and dashboards across, and only then drop it from Dremio’s catalog – after checking that the drop won’t garbage-collect the shared files. For the pilot, clone a few representative tables into a separate path first (a CREATE TABLE AS SELECT out of Dremio does it), so neither system can ever disturb the other’s data.
For teams under financial regulation
To be on the safe side, we like to say: this is purely information, not legal advice from our side. Under the EU’s DORA regime, financial entities are expected to know, and document, how concentrated their reliance on any single ICT provider is. A change of ownership is a textbook moment to refresh that record, re-weigh concentration risk if the new owner already appears elsewhere in your critical stack, and look again at your exit terms at the next renewal.
One technical detail earns a line in that review: whether a self-hosted platform reaches out to its vendor on its own. Per Dremio’s own documentation, Enterprise clusters on Kubernetes have, since version 26.0, transmitted operational metrics to an external Dremio endpoint by default; it can be turned off in configuration, and Dremio sets out what is and isn’t sent. That’s common enough for commercial software – but any default outbound link from inside a regulated or air-gapped environment is worth documenting, and, after a change of owner, worth confirming which company now receives it.
Where does Stackable fit in?
If the destination is a fully open-source, self-hosted stack, this is what the Stackable Data Platform (SDP) is for. SDP is a modular, Kubernetes-native data platform that operates Trino for you on any Kubernetes cluster – TLS, OpenID Connect and LDAP authentication, authorization via Open Policy Agent (OPA), monitoring and lifecycle operations – and runs Apache Spark™ on the same cluster for pipelines and machine learning against the same Iceberg tables. Trino handles the interactive SQL that Dremio users expect; Spark covers heavier batch work. It’s the pattern shown in the Trino-and-Iceberg lakehouse demo.
Two things make it a natural landing spot for a move off Dremio. First, it is 100% open source – operators under OSL-3.0, data apps under Apache 2.0 – so security, authorization and supply-chain features aren’t gated behind a commercial tier; there is no open-core line to re-cross. Second, it runs entirely in your environment, on-premises or in any cloud, including air-gapped installations, which keeps data sovereignty and a fully traceable software supply chain (SBOMs included) in your hands.
So, should you move?
Two questions decide it more cleanly than any feature list.
First: is your organisation already heading toward SAP? If so, staying is coherent – press SAP for written answers on the self-hosted edition’s roadmap, on licensing that stands on its own without a wider SAP agreement, and on the connectors you depend on, and you have what you need.
Second: was independence, open formats, or keeping data in your own hands part of why Dremio was chosen? Then run a small, real test before your renewal date – clone a few representative tables, register the copies in Trino, port your most-used views, and compare on the workloads you genuinely care about rather than a benchmark. The aim isn’t to leave; it’s to know what leaving would cost before you ever have to.
Whichever way it lands, the cheap insurance is the same: keep your tables in open Iceberg on storage you control, and make sure your catalog, policies and lineage can be exported on your terms. Vendor ownership can change again – a lakehouse you can pick up and carry doesn’t much care who it changes to.
Next steps
The lowest-risk way to find out whether Trino fits is to try it on your own data without touching production: stand up Trino with the Stackable Operator for Trino, register a handful of copied Iceberg tables, and run your heaviest dashboards against both engines. The lakehouse demo shows Trino, Spark and Iceberg working together, and the plans page covers where free self-operation ends and commercial support begins.
And if you want the open platform without running Kubernetes yourself, Stackable can operate it for you as a managed data lakehouse – the same open-source stack and the same freedom to leave, with the day-to-day operations handled on your behalf.
FAQ
Does the SAP acquisition force a migration?
No. Nothing stops working, and for SAP-centric teams staying may be the better call. Treat it as a prompt to re-check vendor concentration, exit terms and how portable your stack is – not as a deadline.
Can I switch engines without re-ingesting my data?
If your tables are Iceberg in your own object storage, yes. Trino’s register_table adds an existing table to a new catalog by referencing its current metadata, so the underlying files are left untouched. Views, Reflections, live connections and access rules are separate pieces of work.
Why Trino rather than Spark for this?
Both read the same Iceberg tables, so either works. Trino is usually the gentler landing for Dremio users because it’s built for interactive SQL and the analyst-facing querying Dremio is known for, while Spark earns its place for heavier batch and machine-learning work. On the Stackable Data Platform you can run both on one cluster, so it needn’t be either/or.
Is it safe to run Trino and Dremio against the same tables during the move?
Not through two catalogs at once – each tracks the table’s state independently, and Dremio’s cleanup can delete files Trino still needs. Keep the pilot on copies and register each real table a single time, at its cutover.
What happens to Dremio Reflections?
They don’t carry over – Reflections and their automatic query-rewriting are Dremio-only. You re-create the acceleration deliberately with pre-aggregated tables, partitioning, sort order and compaction, and verify it against the dashboards that matter most.
Does Stackable have its own query engine?
No. Stackable operates Trino and other open-source engines on Kubernetes; it doesn’t build or sell an engine of its own.