Databricks answers,without a notebook or a line of SQL.

Tell the Connector Agent you want Databricks, or choose its card in the catalog. Enter the server hostname and HTTP path from your SQL warehouse's Connection details, then a service principal's OAuth credentials or a personal access token in the secure form. Optionally name a catalog and schema. Then pick the tables, choose which stay Live and how often the rest refresh, and approve.

The tables and views in the schema you choose, either all of them or a list you pick, with their columns and types. It works with Unity Catalog or the Hive metastore, through a SQL warehouse. Querri can only read what the token's user or service principal can read.

Synced tables are re-read in full daily, weekly or monthly, so rows changed or deleted in Databricks show up after the next run. Before a big meeting, start one by hand. Live tables are always current: each question reads Databricks as it is when it runs.

No. Querri only reads your Databricks tables and never changes a record in them. It runs schema lookups and SELECT queries and never creates, updates or deletes a table or row; Live queries are checked before they're sent, so only a single SELECT over the tables you chose reaches Databricks. Those queries do run on your warehouse, so syncs and Live questions use its compute.

Querri can only read what the service principal or the token's user is granted, so a service principal with read access to just the schema you want is the cleanest setup. Inside Querri, Unity Catalog grants don't apply person by person: Querri's sharing settings and a row filter for each person decide what they see, and for Live tables that filter is applied inside the Databricks query.

It can, table by table. A Live table stays in Databricks: each question that needs it runs on your SQL warehouse as a query written in Databricks SQL, and only the result comes back. Those queries use the warehouse's compute, and a stopped warehouse adds a few seconds to the first question. Synced tables are answered from Querri's copy, so those questions never wake a SQL warehouse and reflect the latest sync. Live tables are available in Scale plans.

Make it Live when the table is very large, when the data must stay in the lakehouse, or when every answer should reflect Databricks as it is now. Keep it synced when the table is small or medium, when people explore it heavily and you'd rather not pay warehouse compute per question, or when the warehouse is slow to start. You can switch a Live table back to synced at any time; it loads on the next full sync.

Yes. Questions over several Live tables from the same connection run as one Databricks query. When a question also needs a synced table or an uploaded file, Querri first summarizes the Live table in Databricks, then combines the small result with the other data in Querri. It happens automatically, and clicking a number shows which table it came from, with a Live badge.

Connect NetSuite as well, and both land in the same Library. Querri can match lakehouse usage, orders or shipments to NetSuite invoices, sales orders and payments on a shared order number or customer, and it tells you how it matched. Define once which usage is billable or when an order counts as shipped, and every answer follows it.

Connect Salesforce next to Databricks. Querri matches accounts across the two, best on an ID stored in both, so you can put product or order activity beside pipeline, renewals and open cases. If a match rests on a name rather than an ID, the answer flags it.

Turn the analysis into a project and attach a weekly schedule. On Monday morning it reruns on current lakehouse data and sends each manager a formatted workbook holding only their region, or one per client. The download-and-paste step goes away.

Connect the Delta table your model writes its forecast to, plus the orders or sales table, live or synced. Define forecast error once as a KPI, broken out by region or product. Querri keeps its history from the day you start, and Nightly insights flags a region whose error drifts.

Yes. Ask for the dashboard in plain words, or start from a screenshot of one your team already uses, and change it by asking. A single dashboard can mix lakehouse tables with ERP, CRM or spreadsheet data, hold each viewer to their own rows, and be embedded in your own app.

Yes. After a one-time setup in Claude or ChatGPT, questions about lakehouse tables draw on your Querri Library, follow your definitions and rules, and stay inside what that person may see in Querri, so the assistant and your dashboards agree.

Yes. OAuth with a service principal (machine-to-machine) is the recommended setup: enter its client ID and secret, and its short-lived tokens need no rotation. A personal access token also works. Either way, the connection doesn't depend on any one employee signing in.

A connection covers a single catalog and schema. Custom SQL queries aren't supported, so select tables or views instead. There's no writing back. Live results stop at 100,000 rows and questions in chat time out after 2 minutes, by default. Several catalogs or schemas simply mean several connections.

Not yet. Querri connects to your workspace over HTTPS on port 443, so the workspace has to be reachable from the internet. If a warehouse is stopped or the host is wrong, the connection gives up within a couple of minutes rather than hanging.

Yes. Make a big table Live and it stays in Databricks, where each question runs and only the result comes back. Synced tables stream in chunks of 50,000 rows into typed Parquet files, rather than one giant pull, and progress shows as rows arrive. You can also cap rows per table.

No. Once the tables are connected, anyone with access asks in plain language. Querri shows the steps behind each answer, so someone on the data team can check the logic, and a good answer can be saved as a project that reruns on fresh data.

Querri is SOC 2 Type II, HIPAA and ISO 27001:2022 certified, and your data is never used to train a model. Your credentials are encrypted at rest, scrubbed from error messages and never shown to the Connector Agent, and the connection uses HTTPS only.