Dual Execution

When a query touches both lake-synced and Snowflake-only tables, melt’s router splits the plan: Snowflake-resident operators ship to Snowflake, the rest run in DuckDB, and Arrow batches stitch the result. No whole-query fallback, no SQL changes.

How it works

Dual Execution in three steps.

01

Parse and classify placement

The proxy parses incoming Snowflake-dialect SQL and walks every ObjectName.

02

Build the hybrid plan

The plan builder walks the AST and produces an Arc<HybridPlan> whose root: PlanNode tree carries Placement annotations and RemoteSql collapse nodes.

03

Choose a strategy per fragment

BridgeStrategy::Attach for single-scan nodes — run as sf_link.

What you get

Drop in. Same drivers. Lower bill.

No more all-or-nothing cliff

Without dual exec, one Snowflake-only table forces the entire query back to Snowflake — even if 90% of the bytes are lake-resident.

Sub-query level cost reduction

The router’s pushdown collapse rule turns multi-table remote subtrees into a single Snowflake-side join, executed natively.

Parity-checked correctness

Every hybrid query is eligible for replay against pure Snowflake at hybrid_parity_sample_rate.

Get up and running in 5 minutes.

Connect your Snowflake account, swap your connection string, and watch your warehouse credits drop.