Start with the workload, not the vendor checklist

Databricks combines data engineering, SQL warehousing, governance, notebooks, machine learning, and AI services. Replacing every part of that platform with one smaller product is usually the wrong goal.

First decide what you need from the lakehouse layer: embedded queries, distributed federation, a programming library, or an always-on SQL service over open tables.

DuckDB: embedded and local-first

DuckDB is a strong choice when analytics should run inside an application, notebook, or local process. Its current Delta extension and Iceberg extension continue to expand lakehouse support.

Look beyond an embedded model when many users need a shared endpoint, centralized permissions, BI connectivity, or long-running operational workloads.

Trino: distributed SQL

Trino is a distributed SQL query engine designed for large data sets across heterogeneous sources. It is a good fit when federation and horizontal query execution are the main requirements.

The trade-off is operational scope: Trino uses coordinators and workers, plus catalogs and the infrastructure needed to run a distributed service.

delta-rs: a library inside your application

delta-rs provides Python and Rust APIs for reading and writing Delta tables. It is useful when table operations belong inside application code or a pipeline.

It is a library rather than a shared SQL service. Your application owns orchestration, authentication, concurrency, and client connectivity.

DeltaForge: a self-hosted SQL service

DeltaForge is commercial, customer-installed software for teams that want an always-on SQL endpoint without Spark or a JVM. It reads and writes both Delta Lake and Apache Iceberg, supports full DML and time travel, and exposes native ODBC and ADBC drivers.

It is not a notebook platform or a managed AI suite. The narrower scope is the point: SQL operations and BI connectivity over open lakehouse tables in your own environment.

Decision table

Choose DuckDB
When one process should query data with minimal infrastructure.
Choose Trino
When distributed federation across many sources is the primary job.
Choose delta-rs
When Delta operations should be embedded in Python or Rust code.
Choose DeltaForge
When multiple clients need a self-hosted SQL service with Delta and Iceberg DML.
Choose Databricks
When you want the broader managed platform and its integrated services.

FAQ

When do teams outgrow DuckDB?

Usually when the workload needs a shared service boundary: multiple users, BI tools, centralized access, or continuous operational DML.

Is DeltaForge open source?

No. It is commercial software with a Community tier. The tables remain standard Delta Lake or Apache Iceberg.

Can I keep using other engines?

Yes. Open table formats let compatible engines share the same storage. See Delta Lake vs Iceberg for the format-level comparison.

Run it yourself

Try DeltaForge against an existing table in your own environment. Start with the install guide, review pricing, or get a Community license from the DeltaForge console.