← Use cases

Spin up ephemeral databases for scratch work

Exploratory SQL is easier when you're not leaning on shared prod or a crowded staging schema. Create a throwaway instant database with an expiry, load and query in isolation, then let it disappear — no cleanup, no stepping on teammates or shared quotas.

How it works

Step 1: Create an ephemeral database

Spin up a throwaway database called scratch that auto-expires in 24 hours, so my experiments don’t linger.

Step 2: Explore and query

Show the columns on our product analytics data source, then give me event counts by week for the last 24 weeks from the events table.

Step 3: Load a one-off file into it

Load segment.parquet as a high_value_users table in my scratch database. What table name do I query afterward?

Step 4: Point the rest of your session at the sandbox

databases use makes a database the default target for later commands, so one-off exploration lands in the throwaway instead of a shared database. It takes the database id that create prints. Combined with --expires-at at create time, the sandbox cleans itself up.

Create a throwaway database for a one-off exploration, make it my default so my next queries land there, and let it auto-expire.

Step 5: Isolate messy uploads in their own throwaway database

I’m loading a rough partner extract for a one-off QA join. Keep it in a throwaway database that expires so it doesn’t linger after we’re done.

Step 6: Tear it down when you're done

Delete early, or just let expires_at clean it up for you.

I’m done with the scratch database — tear it down now instead of waiting for it to expire.

Who uses this

  • Analysts prototyping joins before promoting logic to scheduled jobs.
  • Agents that need real compute on temporary data, kept in a database that expires after the task.
  • Platform folks who don't want half the company experimenting on one shared warehouse role.