Why DeltaForge exists

Most business data is still relational: tables, joins, aggregates, operational records. Putting it in a lakehouse doesn't mean every job needs a distributed engine. Selective, frequent, and metadata-heavy workloads run faster with direct execution.

DeltaForge is built for this middle ground.

It runs native agents directly on Delta Lake and Apache Iceberg, with no Spark cluster and no JVM to operate, scaling across workers only when a job actually needs it.

POSITIONING middle ground · operational lakehouse driver DISTRIBUTED CLUSTER heavy coordination proc EMBEDDED ENGINE single-process DELTAFORGE native agents · concurrent · scale on demand selective · operational · metadata-heavy jobs

Pick the view that fits

Same product, two lenses.

For Developers

Single binary, standard SQL, native ODBC/JDBC/Python/R/.NET drivers, MCP for AI tools, and a property-graph layer over the same Delta and Iceberg tables.

Read the developer view

For Executives

Query the lake directly, pay only for active compute, verify every number against Apache Spark. Fewer systems, lower bills, data you actually own.

Read the executive view

Frequently asked questions

Yes. DeltaForge reads and writes the same Delta Lake and Apache Iceberg tables, but runs native agents directly on the data with no Spark cluster and no JVM. Because the table formats are standard, every write stays verifiable against Apache Spark.
Yes. DeltaForge installs in your own cloud account or your own datacenter. The data, the catalog, and the compute all live where you put them, which makes it a self-hosted alternative to managed lakehouse platforms.
Yes. Distributed execution exists for workloads where it genuinely helps, but it is opt-in. The default is direct execution on a single worker.
Between a distributed cluster engine and a single-process embedded engine. DeltaForge runs concurrent native agents on Delta and Iceberg tables in place.

Further reading