One engine for your SQL and your Spark.

Most teams end up running two: a SQL warehouse for the dashboards and a Spark cluster for the pipelines and notebooks. That means two bills, two sets of permissions, and a copy of the data in between.

Databasin Sail is one engine that does both. Your dashboards, your notebooks and your PySpark jobs all run on the same tables under the same rules. It starts in seconds and scales to zero when nobody’s using it.

Start free Book an hour with Chris

The dashboard and the data engineer share one engine.

Here are the three people who usually wait on two different systems, and what changes for each of them once there’s only one.

The analyst in Tableau Why does the dashboard crawl when the whole team opens it on Monday?

Tableau and Power BI connect to Sail like any Spark SQL warehouse. In our tests 200 short queries fired at once all came back, the slowest within 2.5 seconds.

The data engineer Why does my notebook wait five minutes before it does anything?

It doesn’t any more. The same engine that answers the dashboard runs your PySpark, and it starts in seconds, so nobody leaves a cluster running all afternoon to avoid the wait.

Whoever pays the bill Why are we paying for two clusters, and for the weekend?

There’s one cluster to pay for, and its workers scale to zero when idle. A weekend with no queries costs nothing in compute.

Query Unity Catalog without spending DBUs. Preview

Already on Databricks? Unity Catalog is a native connector. Add your workspace URL and a token, and its catalogs show up in Sail next to everything else. Sail reads the Delta tables straight from storage with the short-lived credentials Unity Catalog hands out, so Unity Catalog’s own grants still decide who sees what.

No Databricks compute starts, so those queries don’t use DBUs. Your team can ask Databasin One about those tables in plain English, or open them in a notebook, and pay for Sail minutes instead. For teams watching their DBU spend, that’s a gentler way to bring it down without moving anything.

Try it on your workspace with us →

Same governanceReads go through Unity Catalog’s permissions and its short-lived storage credentials. We never hold a standing key to your storage.
No Databricks computeNothing runs in your workspace. Your SQL warehouses stay asleep.
Where it stops todayRead-only, tables but not views, on shared Sail clusters. A table with row filters or column masks is refused rather than shown unfiltered.

Your app and your analytics on the same data. Private preview

Turn on OLTP mode and a Sail cluster gets its own PostgreSQL database. It’s real Postgres, so your applications read and write it with any Postgres driver, with full ACID transactions.

Sail sees that database as a live catalog. Spark SQL and PySpark can query it directly and join it to the lakehouse, so one query can put this minute’s orders next to five years of history. We’re adding table sync during the preview, so you can copy tables between Postgres and the lakehouse in either direction and keep a Postgres table synced into the lake automatically.

OLTP mode is invite-only while we build it out with early customers. Ask to join.

-- this minute, from the app’s Postgres (OLTP mode)
-- against five years of history in the lakehouse
SELECT o.region,
       sum(o.amount)       AS today,
       avg(h.daily_amount) AS typical_day
FROM   oltp.public.orders     o
JOIN   lake.sales.daily_totals h
  ON   h.region = o.region
WHERE  o.created_at >= current_date
GROUP BY o.region;

The same Spark API, on a different engine underneath

Sail speaks Spark Connect, so PySpark DataFrames, Spark SQL and notebooks connect the way they always have. Underneath is Sail, LakeSail’s open-source engine on Apache DataFusion, with our own changes for the lakehouse: our catalogs, our permission rules, and live sources. What we built on, and what we added.

It reads and writes the same lakehouse tables as the rest of Databasin, under the same permissions, so there’s never a separate copy for Spark. We built it that way because copies of a table drift apart over time.

Your Spark code, unchangedPySpark DataFrames, Spark SQL and most of Spark’s built-in functions. Python and pandas UDFs on single-user clusters.
The lakehouse, read and writeIceberg with CREATE, INSERT, UPDATE, DELETE, MERGE, OPTIMIZE, VACUUM and metadata tables. Delta Lake read and write.
Live databases in the same queryPostgreSQL, MySQL and SQL Server appear as catalogs you name, with filters and limits pushed down to the source. Databasin API and file sources work live too.
Built for BI trafficJDBC, ODBC and Thrift drivers for Tableau, Power BI and DBeaver. Schemas and columns browse in under two seconds on a cold cluster.
Governed and recordedThe same table and column rules as the rest of Databasin, Python sandboxed per user, and every query in Query Activity: who, what, how long.

How a Sail cluster runs a query

Every cluster has a small coordinator and a set of workers. The coordinator plans each query and checks the access rules; it can stay on so tools connect instantly, or sleep with the rest. The workers do the heavy lifting: they start when someone connects or runs a query, read and write the lakehouse or reach live sources in place, and scale back to zero once things go quiet.

1 · Connect

DatabasinSQL editor, notebooks, Databasin One, Data Apps, automations

PySpark and notebooksJupyter, VS Code and scripts over Spark Connect

Tableau and Power BISpark connectors over HiveServer2, with HTTPS

DBeaver and JDBC appsThe Apache Kyuubi JDBC driver; the HTTP path picks the catalog

2 · Coordinator

Small, stays on or sleepsChecks TLS, the password and the cluster’s network rules.Answers schema and table browsing itself, so BI tools don’t wait for workers to start.every statement lands
in Query Activity

3 · Workers and storage

Sail workersThe query engine, in Rust on Apache DataFusion. Workers scale to zero about half an hour after the last request and are billed only while they run; the coordinator is billed while it’s on. vectorized Arrowjoins that spillruntime filtersread cacheArrow Flight shuffle

LakehouseIceberg and Delta tables in your storage, read and write, shared with your pipelines

OLTP modeprivate previewA Postgres database on the cluster, queried as oltp

4 · Live sources

DatabasesPostgreSQL, MySQL and SQL Server, with filters and limits pushed down

SaaS APIs and filesMost Databasin API and file connectors, queried without a pipeline

DatabricksUnity Catalog tables, read in placepreview

Across all of it: one set of table and column rulesprivate, specific IPs or open network accessopen formats in your storage

How Sail compares with Trino and Databricks

Databasin also runs Trino, for teams that already write ANSI SQL and want to keep it. It reads the same tables under the same permissions, so it’s an option, not a second copy of anything. If you’re weighing Sail against Databricks, that column is here too.

Feature	Databasin Sail	Trino in Databasin	Databricks
SQL dialect	Spark SQL	ANSI SQL	Spark SQL
Engine underneath	Rust on Apache DataFusion	Java	Spark on the JVM, with the Photon engine
PySpark and the DataFrame API	Yes	No	Yes
Spark Connect from Jupyter, VS Code, scripts	Yes	No	Yes, Databricks Connect
Python and pandas UDFs	Single-user clusters	No	Yes
Notebooks	SQL and Python	SQL	SQL, Python, Scala and R
Iceberg read and write, MERGE, OPTIMIZE, VACUUM	Yes	Yes	Yes, managed Iceberg tables
Delta read and write	Yes	Yes	Yes
Live PostgreSQL, MySQL, SQL Server	Yes, with pushdown	Yes, with pushdown	Yes, Lakehouse Federation
Live SaaS APIs, no pipeline first	Yes, most API connectors	Yes, most API connectors	Mostly ingest first
Unity Catalog read without Databricks compute	Preview	No	Uses Databricks compute
BI tools	Spark / HiveServer2 drivers	Trino drivers	Databricks drivers
Table and column access rules	Yes	Yes	Yes, Unity Catalog
Row filters and column masks	Not yet	Row filters	Yes
Scale to zero	Yes	Yes	Yes, serverless
A Postgres database beside the lake	OLTP mode, private preview	No	Yes, Lakebase

The Databricks column follows Databricks’ public documentation as of October 2026; what’s available varies by cloud, tier and region, so check theirs before you rely on a cell. Apache Doris and DuckDB also run on the same tables for teams that already rely on them. Every engine, in the docs.

What Sail doesn’t do yet

Sail runs Python and SQL. It doesn’t run Scala or Java code, RDDs or pyspark.ml, and a small set of Spark functions still behave differently. Python UDFs need a single-user cluster today; a sandbox that makes them safe on shared clusters is on our list. Row filters and column masks aren’t supported yet: a table whose rule uses one is refused rather than shown unfiltered.

Next on our listWrites to Unity Catalog, more live sources (Snowflake, BigQuery and Oracle), and faster very large aggregations.

Built on open source, shaped for production

Databasin Sail stands on the shoulders of two excellent open-source projects: Sail by LakeSail, a Spark-compatible engine written in Rust, and Apache DataFusion, the fast, extensible query engine it runs on, with Apache Arrow and Parquet underneath. We love open source, and we wouldn’t have Databasin Sail without the people who build these projects.

We started from them and made the changes our customers needed to run them in production. We keep those changes as separate patches on top of the upstream projects, so your cluster keeps getting the community’s improvements too.

Sail and Apache DataFusion are Apache 2.0 licensed. Apache DataFusion and Apache Arrow are trademarks of the Apache Software Foundation. Neither LakeSail nor the Apache Software Foundation endorses Databasin.

A cluster that scales to zeroWorkers start when you query and scale to zero when you stop, on Azure Container Apps in your region.
Your permissions, everywhereThe same table-level access rules as the rest of Databasin, enforced inside the engine. Pipeline-managed tables stay read-only, and Python runs in an isolated sandbox per user.
All your data in one placeYour Iceberg lakehouse, Delta tables shared with Trino, and live sources such as databases and Databricks Unity Catalog, queried together.
Big joins that finishJoins larger than memory spill to disk instead of failing. A broadcast table is built once per node, not once per task, and runtime filters skip data a join will never need.
Faster on repeatA local read cache on every node, and fair memory sharing so a small query isn’t stuck behind a big one.
Your BI tools, unchangedTableau and Power BI connect over the standard Thrift/HiveServer2 protocol.
Real-world data reads correctlySpark-compatible handling of files written by Databricks and older Spark (legacy timestamps, optional fields into required columns), more Spark SQL functions, and MERGE, UPDATE and OPTIMIZE on Iceberg.
You can see what’s happeningA query monitor, cancel, and per-operator profiling.

Bring a slow notebook, and we’ll run it on Sail with you.

Start free Book an hour with Chris

Chris Lundeberg, one of our co-founders, runs the technical demos himself. Bring your hardest data problem; he’d much rather work on that with you than show slides.