Connectors

Live connections (no sync)

Query a source directly from SQL through the live catalog, with nothing to sync first.

Last updated August 10, 2026
Reading time 3 min read

Normally you get data into Databasin by syncing it — a pipeline copies rows into your lakehouse, and you query the copy. A live connection skips that step: you write SQL and Databasin queries the source directly, right then.

This is query federation, and it's the fastest way from "I just connected something" to "I have an answer."

Beta

Live connections carry a Beta badge. They work, and they're the right tool for exploration — but for anything you'll run repeatedly, syncing is still faster and cheaper.

When to use it

Use a live connection when… Sync instead when…
You want to look at a source right now. The same query runs every day.
You're exploring, and don't know what you need. A dashboard or report depends on it.
The data must be current to the second. You need history the source doesn't keep.
You're deciding what's worth syncing. The queries are heavy, or the source is rate-limited.

Every live query hits the source, so the source's speed and rate limits are your speed and rate limits. That's the whole trade: no wait to get started, no free lunch on repeat.

What you need

Live connections run through a Databasin plugin hosted by your query engine, so:

  • Trino and Doris can host it. ✅
  • Spark, DuckDB, and Databricks cannot — they read the shared metastore instead of running a catalog server, so there's no live catalog for them.

If your project's lakehouse is Spark or DuckDB, the option is offered but disabled, with a note to create a Trino or Doris lakehouse first.

Setting one up

From Integrations → Create integration, pick Set up a live connection. That takes you to your lakehouse with the add-live-source flow open.

You can also get there from the SQL editor: in the Object Explorer, under Other Data Sources, open the Live Sources panel.

The panel lists every connector in the project that's eligible, and each row tells you where it stands:

  • Live — already queryable. A badge shows whether it's queryable under the live catalog or as its own catalog.
  • Make live — eligible, one click away.
  • Lakehouse only — the live plugin can't query this source. Sync it instead.
You don't need a running cluster to set it up

Setting a source live works whether or not compute is awake — you only need a running cluster to actually run a query against it. If the cluster is asleep, the lakehouse offers Start when you get there.

Querying a live source

Once a source is live, it appears as a schema you can query like any other:

SELECT id, name, created_at
FROM live.hubspot.contacts
WHERE created_at > current_date - interval '7' day

Because Trino federates across catalogs, you can join a live source to data you've already landed:

SELECT o.id, o.total, c.email
FROM warehouse.public.orders o
JOIN live.hubspot.contacts c ON c.id = o.contact_id

That's the pattern that makes live connections worth having — "I haven't synced this yet, but I need it in this one query."

Turning it off

Each live row has an off switch. Turning live off removes the source from the live catalog and takes about 60 seconds to take effect. Nothing is destroyed — you can make it live again at any time.

A federated source (an RDBMS that is its own catalog) has no off switch here; remove it through catalog management instead.

Limits worth knowing

  • Pushdown varies by source. Databasin pushes filters and limits into the source where the source's API supports it. Where it can't, more rows come back before filtering, and the query is slower.
  • It's a source query, not a warehouse query. A live query is subject to the source's rate limits and its idea of consistency.
  • No history. You see what the source has now. If you need "what did this look like last month," sync it.

Where to go next