Control spend and long-running hybrid queries
Some queries finish in milliseconds; others chew through huge tables. Async execution, saved results, background refreshes, and a single place to watch jobs mean you're not guessing what's still running or re-paying for the same read twice.
How it works
Step 1: Prefer async when integrations might lag
How many events did we get today in the huge events table? If the answer isn’t ready yet, show me how to check when the count is done.When waiting synchronously isn't worth it, the CLI hands back a query_run_id. Poll status instead of blocking on the terminal.
Step 2: Reuse stored results instead of re-running
Show my last 5 query runs, then let me read the stored rows from one of them without re-running the same SQL.Step 3: Tune connection refresh, not blind rescans
Our shared finance Snowflake is out of date. Refresh it so the table list here matches the warehouse again.connections refresh reconciles the catalog in the background. Give it a moment before you trust tables list for brand-new upstream DDL.
Step 4: Watch jobs that balloon latency
What’s running in the background right now? Then show me full detail for one of those runs.jobs list shows what's still running: long index builds, refreshes, whatever's in flight. jobs <id> tells you when it's finished.
Who uses this
- Finance or ops tying spend and latency back to query-run metadata.
- ML or eval pipelines firing lots of short reads against shared warehouses. Reuse results instead of repeating work.
- Anyone who'd rather poll or reuse than block on long-running hybrid queries.