DeltaForge queries Apache Iceberg with SQL from a single binary: no Spark cluster, no JVM. It reads native Iceberg tables and writes Delta tables with Iceberg metadata via UniForm. The same SQL dialect, the same optimizer, and the same ODBC driver work across both formats.
Read and write, not just one or the other
DeltaForge reads tables written by other Iceberg-compatible engines. The same SQL dialect, predicate pushdown, and column pruning that works on Delta tables also works on Iceberg tables. Query both in one statement.
Enable UniForm on a Delta table and DeltaForge writes Iceberg metadata (metadata.json, manifest list, manifests) on every commit. Delta readers and Iceberg readers see the same physical Parquet files. No ETL, no data duplication.
Join a Delta table and an Iceberg table in one query. Predicate pushdown reaches into each format's native metadata layer independently.
SELECT d.order_id, i.status
FROM delta.warehouse.orders d
JOIN iceberg.warehouse.shipments i
ON d.order_id = i.order_idNo mode switching, no separate catalog, no connector configuration. Register a storage credential, point at the table path, and use the same SELECT, INSERT, UPDATE, DELETE, MERGE INTO, ALTER TABLE, and time travel syntax you already use on Delta tables.
MERGE INTO iceberg.warehouse.shipments t
USING staged_updates s
ON t.shipment_id = s.shipment_id
WHEN MATCHED THEN UPDATE SET status = s.status
WHEN NOT MATCHED THEN INSERT (shipment_id, status)
VALUES (s.shipment_id, s.status)Write Delta, expose Iceberg, no pipeline in between
A SQL write commits a Delta log entry. DeltaForge then generates the corresponding Iceberg metadata inline: metadata.json, a manifest list, and one manifest per partition. Both metadata layers reference the same Parquet files.
Teams that use DeltaForge for writes and maintenance, while downstream consumers use an Iceberg-compatible engine for reads. Gradual migration from Delta to Iceberg without rewriting existing pipelines.
Snowflake treats externally managed Iceberg tables as read-only on its side: another engine has to do the writing. DeltaForge fills that role. It runs the inserts, updates, merges, and maintenance against the table on object storage, and Snowflake keeps reading the Iceberg metadata it points at.
One table property activates UniForm on an existing Delta table. All subsequent commits produce both sets of metadata automatically.
ALTER TABLE events SET TBLPROPERTIES (
'delta.universalFormat.enabledFormats' = 'iceberg'
)Multi-level skipping from partition to file to row
Predicates on partition columns eliminate entire partitions from scan. The manifest list carries partition summaries so irrelevant manifests are skipped without opening them.
Each manifest records column-level min/max bounds per data file. The optimizer uses these to skip files that cannot contain rows matching the query predicate.
Only columns referenced in the query are read from Parquet. Iceberg's field ID system ensures correct mapping even after renames or reorders.
Querying Iceberg without a cluster, in practice
Run DeltaForge: a single binary, no Spark cluster and no JVM. Register a storage credential, point at the Iceberg table path, and query it with standard SQL. The native reader handles the metadata layer for you, and the same engine also speaks Delta Lake.
Yes. The DeltaForge ODBC driver serves Iceberg tables through the same SQL engine that serves Delta tables, so Power BI, Excel, Tableau, and other ODBC clients can query Iceberg directly.
Yes. DeltaForge executes INSERT, UPDATE, DELETE, and MERGE INTO against Iceberg tables with standard SQL from a single binary, with no Spark cluster and no JVM. The same DML syntax used on Delta tables applies unchanged.
For DML on both open table formats, Iceberg INSERT, UPDATE, DELETE and MERGE in SQL, No Spark Required walks the Iceberg side, and MERGE, UPDATE and DELETE on Delta Lake Without Spark covers the Delta side of the same engine.
Native Iceberg and Delta Lake in the same SQL engine. Your data, your format, your choice.