Multi-engine SQL
Trino, Doris, Spark, DuckDB, and Databricks from one editor.
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 standard SQL, and let Databasin handle the plumbing underneath.
Why multiple engines exist
Each engine has a specialty. The native set is Trino, Doris, Spark, and DuckDB; Databricks is supported as an external/federated connection.
| Engine | Best for | Notes |
|---|---|---|
| Trino | Interactive SQL, federated queries across catalogs | Streams results · needs a cluster |
| Doris | Real-time OLAP — low-latency, high-concurrency analytics and BI | Streams results · needs a cluster |
| Spark | Heavy ETL, large-scale processing, advanced analytics | Batched · needs a cluster |
| DuckDB | Small-to-medium data, fast single-node prototyping | Batched · single-node |
| Databricks | Querying an existing Databricks workspace from the same editor | External · Databricks-native billing |
For most teams the sweet spot is Trino for the bulk of the work, Doris when latency and concurrency matter, and one of the others for specific jobs.
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
Engines mostly speak the same SQL, with small differences at the margins — timestamp parsing, array functions, and the like. Autocomplete suggests catalogs, schemas, tables, and columns; it does not rewrite functions for you or filter suggestions by dialect.
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 Doris versus Trino, ask the assistant rather than hand-translating.
The 95% of an analytical query that's portable, you'll write yourself. For the 5% that's engine-specific, the SQL Assistant already knows the target dialect — lean on it instead of memorizing every function name.
Federated queries
Trino is the engine that can query across multiple catalogs in a single statement. So a query like this is legal and useful:
SELECT
o.id,
o.total,
c.name
FROM warehouse.public.orders o
JOIN postgres_prod.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 connection in one go — handy for "I haven't pipelined this yet but I need it in this query."
Query routing under the hood
- Trino, Doris, Spark, and DuckDB route through the universal Databasin query API.
- Databricks routes through a proxy — same editor surface, different plumbing.
- Streaming is Trino and Doris only. Their results arrive as they're produced; Spark, 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 Trino, Spark, and Doris clusters use Iceberg as their table format (since 2026-03-24). That buys you:
- Schema evolution without rewrites.
- Time travel for a configurable retention period.
- Compatible reads across engines without translation.
Existing Delta Lake tables continue to work — Databasin just doesn't create new ones in that format.