Multi-engine SQL

One of Databasin's unusual capabilities is that the same SQL editor can talk to several different query engines. You pick the engine that fits the job, write SQL, and let Databasin handle the plumbing underneath.

The engines

The native engines are Databasin Sail, Trino and DuckDB; Databricks is supported as an external connection.

For most teams the sweet spot is Databasin Sail for the bulk of the work, with Trino added when you need to federate many outside databases at once. See Databasin Sail for everything Sail does.

One engine at a time

The editor talks to one engine at a time, and that choice applies to the whole editor. Every tab. There's a single connection picker at the top; switch it and you re-target all your open tabs to the new engine.

Tabs each remember their own query text, results, and errors, but they share one connection. So there's no "Trino tab sitting next to a Databricks tab"; to compare engines, switch the connection and re-run. The trade-off is simplicity: you never have to wonder which engine a given tab is pointed at.

Dialects and the AI SQL Assistant

The engines speak two dialects:

• Spark SQL on Databasin Sail and Databricks. See the Sail SQL reference.
• Trino SQL on Trino, and DuckDB's own SQL on DuckDB.

Most analytical SQL is portable between them; the differences sit at the margins (timestamp parsing, array functions, and the like). Autocomplete suggests catalogs, schemas, tables, and columns; it does not rewrite functions for you.

The place that actually knows your dialect is the AI SQL Assistant. It sees which engine you're connected to and generates engine-correct SQL for it. If you're unsure how to express something on Sail versus Trino, ask the assistant rather than hand-translating.

Live sources

Databasin Sail and Trino can query sources live, with nothing synced:

• On Sail, each live source becomes its own catalog, named when you make it live. Sail also reads Databricks Unity Catalog tables live.
• On Trino, live sources appear under the live catalog.

DuckDB and Databricks read the shared metastore rather than running a catalog server, so they have no live sources. See Live connections.

Federated queries

Both Sail and Trino can join across catalogs in a single statement, so a query like this is legal and useful:

SELECT
  o.id,
  o.total,
  c.name
FROM gold.sales.orders o
JOIN crm.public.customers c ON c.id = o.customer_id
WHERE o.created_at > current_date - interval '7' day

This joins a lakehouse table against a live Postgres source in one go: handy for "I haven't pipelined this yet but I need it in this query." Trino reaches the most kinds of outside database (including Snowflake and Oracle); Sail covers PostgreSQL, MySQL and SQL Server.

Query routing under the hood

• Databasin Sail, Trino and DuckDB route through the universal Databasin query API.
• Databricks routes through a proxy: same editor surface, different plumbing.
• Streaming: Sail and Trino results arrive as they're produced; DuckDB and Databricks return a batch when the query finishes.

Functionally you shouldn't have to think about any of this. Every engine behaves the same way from the UI.

Iceberg as the default table format

New lakehouses use Iceberg as their table format. That buys you:

• Schema evolution without rewrites.
• Time travel for a configurable retention period.
• Compatible reads across engines without translation: a table Sail writes, Trino reads, and the other way round.

Existing Delta Lake tables continue to work; Databasin just doesn't create new ones in that format.

Where to go next