Get a savings estimate

For teams on Snowflake, Databricks and BigQuery

Take ETL off your warehouse bill

  • Offload ETL from your warehouse and cut its cost 10x
  • Incremental compute on the cheapest engine per job
  • Data written back to your Snowflake, Databricks or BigQuery catalog
  • Deployed entirely in your cloud account
  • Fully automated migration with a transpiler and a 100% match check
Get a savings estimate Book a demo
Monthly ETL cost
On your warehouse
100%
On Zipline
10%

10x lower

Illustrative. Your savings estimate uses your own query history.

Proven in production at

  • A cloud computing company based in San Francisco, California, United States
  • Airwallex

Every job moves to the cheapest engine that can run it

Iceberg tables every engine can read

A warehouse's native format, like Snowflake's FDN or BigQuery's Capacitor, can only be read by that warehouse's engine. Apache Iceberg can be read by all of them. Zipline writes plain Iceberg tables to your object store, so you keep one copy of the data.

Large joins and aggregations go to Spark on spot instances. A 10-row lookup doesn't need a cluster, so it runs on DuckDB. Dashboard queries run on Snowflake, against the same tables.

SQL jobsZipline routerone copy in your object storeorders_gold · IcebergBI dashboard10-row lookupjoins, rollupscheapest engine per jobSnowflakeBigQueryDatabricksDuckDBStarRocksSpark on spot SQL jobsZipline routerone copy in your object storeorders_gold · IcebergBI dashboard10-row lookupjoins, rollupscheapest engine per jobSnowflakeBigQueryDatabricksDuckDBStarRocksSpark on spot

Fully automated migration

  1. Estimate

    A read-only pass over your warehouse's query history ranks your jobs by cost and estimates what each would cost on Zipline. Get yours

  2. Transpile

    Zipline's transpiler rewrites each query for the engine its job will run on.

  3. Verify

    Zipline runs the old and new queries on the same data and compares the results row by row. A job cuts over only once they match 100%.

  4. Cut over

    The new output goes to the same table in your catalog, so downstream queries don't change. Pipelines move one at a time, starting with the most expensive.

Old pipelineSnowflakeNew pipelineZiplinerewritten by Zipline's transpilerorders_dailyorders_dailyZipline validator2026-09-212026-09-222026-09-232026-09-24100% of rows matchcutover Old pipelineSnowflakeNew pipelineZiplinerewritten byZipline's transpilerorders_dailyorders_dailyZipline validator2026-09-212026-09-222026-09-232026-09-24100% of rows matchcutover

Zipline makes joins and aggregations cheap

Most of an ETL bill goes to two kinds of queries: the joins that build silver tables and the aggregations that build gold tables. Zipline buckets, clusters and incrementalizes your tables automatically, so your team doesn't have to tune any of these optimizations by hand.

Incremental aggregations

Take a metric like total revenue per merchant. It typically gets recomputed every day from the entire transaction log. Zipline adds today's partial totals to yesterday's totals, so each run reads one day of raw data. You write the plain aggregation, and Zipline makes it incremental.

Rolling windows work the same way. Zipline keeps partials that cover 1, 2, 4, 8 or more days, so a 90-day window is merged from a handful of them (log N reads) instead of 90 days of raw data.

The savings are 100x or more when a job goes from reading years of raw data to reading a single day.

Usual job, every nightrevenue per merchantAcmeBirchCoveDunereads 1,080 daysabout 3 yearsSame totals, 1,080× less readingZipline, every nightrevenue per merchantAcmeBirchCoveDunereads 1 daytoday only1 square = 1 dayyesterday's totalstoday's partial Usual job, every nightrevenue per merchantAcmeBirchCoveDunereads 1,080 days (about 3 years)Same totals, 1,080× less readingZipline, every nightrevenue per merchantAcmeBirchCoveDunereads 1 day (today only)1 square = 1 dayyesterday's totalstoday's partial

Shuffle-free joins

A join usually sends rows across the network so each one can meet its match. That shuffle is most of the cost of a silver table. If both tables are bucketed the same way in Iceberg, bucket 1 only needs bucket 1, and the join becomes a local merge (Iceberg calls this a storage-partitioned join).

It is hard to set up by hand, so most teams end up with shuffle-heavy jobs that are 5 to 10x slower and costlier. Zipline buckets your tables automatically, so joins on the same key skip the shuffle with no setup.

Shuffle joinorderspayments132421431 ⋈ 1421334212 ⋈ 2243113423 ⋈ 3314242134 ⋈ 4Bucketed joineach row: one nodeorderspayments111111111 ⋈ 1222222222 ⋈ 2333333333 ⋈ 3444444444 ⋈ 45-10x cheaper and faster Shuffle joinorderspayments132421431 ⋈ 1421334212 ⋈ 2243113423 ⋈ 3314242134 ⋈ 4Bucketed joineach row: one nodeorderspayments111111111 ⋈ 1222222222 ⋈ 2333333333 ⋈ 3444444444 ⋈ 45-10x cheaper and faster

Serverless runtime with continuous tuning

Zipline's runtime is fully elastic. A cluster comes up for each job and scales to zero when it finishes, so there is nothing to size or keep running.

Spot nodes make jobs about 4x cheaper, and ARM CPUs with local NVMe drives cut their runtime by about 3x. Each run is tuned from the ones before it.

Zipline also clusters tables along a Hilbert curve automatically, so queries skip the files they don't need.

cluster5 spot nodes (run 1 used 8)spotspotspotspotspotshuffle data on local NVMenodes over timerun 1 · 8 nodesrun 2 · tuned from run 1scaled to zero cluster5 spot nodes (run 1 used 8)spotspotspotspotspotshuffle data on local NVMenodes over timerun 1 · 8 nodesrun 2tuned from run 1scaled to zero

Move dashboard compute to the write side

Dashboards and apps run the same aggregations every time someone opens a page, even though the answer only changes when new data arrives. Zipline computes those results once, when the data lands, and keeps them current.

Gold tables that update when new data lands

The query behind each chart becomes a gold table, and Zipline updates it incrementally as new data lands.

Dashboards in Looker, Tableau or Sigma still query Snowflake, Databricks or BigQuery. They read a few thousand precomputed rows instead of scanning the raw table on every refresh.

Usual dashboard, every refreshDashboardLooker, TableauSnowflake scans orders3 years of raw rowsWith Zipline, every refreshDashboardLooker, TableauGold tablerevenue_dailyZiplineupdates it whennew data lands Usual dashboard, every refreshDashboardLooker, TableauSnowflake scans orders3 years of raw rowsWith Zipline, every refreshDashboardLooker, TableauGold tablerevenue_dailyZiplineupdates it whennew data lands

Real-time metrics from one key lookup

Some numbers have to stay fresh, like a live ops dashboard or a fraud signal. For those, Zipline merges the event stream with batch history as events arrive.

It writes the finished value for each key to the online index, so a read is one lookup instead of an aggregation over recent events.

Event streamKafka, KinesisBatch historyIceberg tablesZiplinemerges both asevents arriveOnline indexkeyorders, last 24 hmerchant_41317merchant_421,284merchant_43961 lookupApp or dashboard Event streamKafka, KinesisBatch historyIceberg tablesZiplinemerges both as events arriveOnline indexkeyorders, last 24 hmerchant_41317merchant_421,284merchant_43961 lookupApp or dashboard

No separate Airflow or dbt code to maintain

Zipline infers the dependency graph from your queries and fills the tables in dependency order on a schedule. If you already run Airflow or dbt, it can plug into them through Iceberg table sensors instead.

Data quality checks are on by default. Zipline profiles every column of every table it writes and flags drift with measures like PSI and Jensen-Shannon divergence, so nobody has to write or tune a check.

You write:5 .sql filesNot needed:airflow_dag.pydbt_project.ymlorders.sqlFROM raw.orderspayments.sqlFROM raw.paymentsorder_pay.sqlJOIN paymentsrevenue.sqlFROM order_payfeatures.sqlFROM revenueruns in dependency orderorderspaymentsorder_payrevenuefeaturesrevenue.amount · on by defaultnull % 0.2 → 31PSI 0.41 · flagged You write:5 .sql filesNot needed:airflow_dag.pydbt_project.ymlorders.sql FROM raw.orderspayments.sql FROM raw.paymentsorder_pay.sql JOIN paymentsrevenue.sql FROM order_payfeatures.sql FROM revenueruns in dependency orderorderspaymentsorder_payrevenuefeaturesrevenue.amount · on by defaultnull % 0.2 → 31PSI 0.41 · flagged

Runs in your cloud account and uses your existing governance

Zipline is self-hosted, so no data or metadata leaves your account. It runs on AWS, Azure and GCP today.

It reads and writes through your existing catalog, such as Unity Catalog, AWS Glue or any Iceberg REST catalog. Zipline's service account only sees what you grant it. The tables it writes are registered in that catalog, so your existing permissions decide who can query them.

You provision
A managed Kubernetes cluster (EKS, AKS or GKE) and an object store (S3, Azure Blob Storage or GCS).
We give you
Helm charts and keys to install Zipline into that cluster.
Your cloud account · AWS · Azure · GCPno data or metadata leavesZiplineon KubernetesYour catalogGlue, Unity Catalogor Iceberg RESTyour permissionsIceberg tablesin object storage Your cloud account · AWS · Azure · GCPno data or metadata leavesZiplineon KubernetesYour catalogGlue, Unity Catalog or Iceberg RESTyour permissionsIceberg tablesin object storage

Online and reverse ETL ready

Zipline combines your warehouse tables and event streams into one online index. It answers search queries and point lookups with p95 latency under 10 ms.

The index holds the features, embeddings and context those systems read. A fraud model can check a customer's features at checkout, and a support agent can pull an account's recent history before it replies.

Teams also use these signals as guardrails for AI agents. Before an agent acts, Zipline can check the action against rules your organization writes.

WarehouseIceberg tablesEvent streamsKafka, Kinesis, Pub/SubOnline indexsearchpoint lookupsp95 < 10 msRecommendationsFraud detectionUnderwritingCustomer supportAgent contextRule enginesApplication metrics WarehouseIceberg tablesEvent streamsKafka, Kinesis,Pub/SubOnline indexsearchpoint lookupsp95 < 10 msRecommendationsFraud detectionUnderwritingCustomer supportAgent contextRule enginesApplication metrics

Built by data infrastructure engineers

We come from Airbnb, Stripe and Google, and we contribute to Apache Iceberg and Spark. Our customers run some of the largest Snowflake, BigQuery and Databricks deployments. They use Zipline to shrink the cost of the ETL that feeds those systems.

Questions

Do we have to leave Snowflake or Databricks?

No. Zipline writes Apache Iceberg tables, and Snowflake, Databricks and BigQuery all read Iceberg. Most teams move the expensive pipelines first and leave dashboards and ad hoc queries on the warehouse.

Do we have to rewrite our SQL?

No. Zipline's transpiler rewrites them for the engine each job runs on, and no job cuts over until its results match the old ones exactly.

Does it work with our existing governance?

Yes. Zipline reads and writes through your existing catalog (Unity Catalog, AWS Glue, Snowflake Open Catalog or any Iceberg REST catalog) with a service account you grant access to. The tables it writes are registered in that catalog, so your current permissions and policies decide who can query them.

We already run Airflow and dbt. Does that still work?

Yes. Zipline can schedule everything itself, and it can also plug into an existing Airflow or dbt setup through Iceberg table sensors, so you can move one pipeline at a time.

What do we need to provision?

A managed Kubernetes cluster (EKS, AKS or GKE) and an object store (S3, Azure Blob Storage or GCS). We give you Helm charts and keys to install Zipline into that cluster.

How long does a proof of concept take?

Typically 2 to 4 weeks, on your own data and in your own cloud account. We start with the jobs that cost you the most.

Get a savings estimate

Tell us which warehouse you use, and one of our founders will get back to you to work out what your ETL would cost on Zipline.

We use your details to respond to this request and discuss your ML goals and a potential business relationship. Read our Website Privacy Policy. Submitting this form does not subscribe you to unrelated marketing.

or book a demo