Sign up now for early access to the Xorq Desktop app Xorq Desktop early access ./waitlist
XorqXorq
./waitlist

Xorq Anywhere

One expression, every engine. Written once in the Ledger, compiled for Snowflake, Databricks, DuckDB, Postgres and more.
productxorq anywhere

One expression. Every engine.

Write the definition once. Xorq compiles it to whichever engine holds the data, moves only the aggregates a step needs, and records one entry no matter where it ran.

xorq anywhere
compileThe same expression becomes native SQL per engine
moveArrow Flight carries aggregates between steps
stayBulk rows never leave the system that holds them
recordOne Ledger entry, one hash, wherever it ran
01write once, run on any engine

Written once in the Ledger. Compiled for whatever holds the data.

An expression in the Ledger is not SQL. It compiles to the SQL of whichever engine it is pointed at, and the hash, lineage, and approval stay the same across all of them.

xorq anywhere · revenue_west_q3 · compile @7be9896e · same hash on every engine
one expression · written once
sales = ledger.source("sales")revenue_west_q3 = (sales.filter(_.region == "West", _.quarter == "Q3").group_by(_.region).agg(revenue=_.amount.sum()))
schema · region: string · revenue: decimal(18,2)sources · sales @v31approved · M. Chen · 2d ago
compiles to
SELECT region, SUM(amount) AS revenueFROM ANALYTICS.SALESWHERE quarter = 'Q3' AND region = 'West'GROUP BY region-- warehouse: FINANCE_WH · dialect: snowflake
same lineage · same cache key · same approvercache HIT on any engine
02multi-engine pipelines

One question, three systems, one answer.

Most real questions span systems. Xorq lets each step run where its data lives and where it is cheapest, then joins the results in a sandbox you control. The Ledger sees one entry.

step 1 · snowflakebilling.invoices · 2.1B rowsFiltered and aggregated where the rows live. Only 40k aggregate rows leave.
step 2 · postgrescrm.accounts · 180k rowsAccount owners and segments, read from the replica.
→→
step 3 · duckdb · local sandboxjoin · enrich · python udfAggregates arrive over Arrow Flight. The join and a scoring UDF run next to the analyst, not in the warehouse.
→
step 4 · ledgerrevenue_by_owner_q3 · @3f1a9c02One entry. Lineage names all three engines and the UDF version. Cached under one hash.
bulk rows stay put·arrow moves aggregates·each step runs on the engine that fits it
03why it matters

Portability, cost, and governance from the same fact.

Because the definition is separate from the engine, the same entry is portable across warehouses, routable to the cheapest place, and governed by one hash.

portabilityMetrics outlive the warehouseA definition is not tied to the dialect it was first written in. Move engines, add a lakehouse, or run locally, and the Ledger entries come along unchanged.
costRoute each step to the cheapest placeHeavy scans on the warehouse, joins and Python in a local sandbox, small lookups on Postgres. The expression decides; nobody rewrites SQL.
governanceOne hash across every engineBecause the key is the expression and its sources, the cache, the lineage, and the approval hold whether the run happened on Snowflake or DuckDB.
04engines

Runs on what you already run.

Connections use your existing credentials. Adding an engine is a profile, not a migration.

Snowflake
Databricks
BigQuery
DuckDB
Postgres
Trino
Parquet · S3 · files
Python UDFs · Arrow Flight
// bring a question that spans two systems

Run it as one expression.

In a working session we take a metric that currently needs an export and a spreadsheet to assemble, and run it end to end across your engines as a single Ledger entry.

Talk to us
also in the platform:xorq ledgerxorq cache