Database Explorer
Browse your warehouse schema interactively. Explore databases, schemas, tables, and columns without writing a single query. Drag objects into the editor to build SQL faster.
Overview
The Database Explorer provides a live, navigable tree of your connected warehouse. It automatically introspects your schema and keeps it up to date as your data models evolve.
Schema Tree
The left panel displays your warehouse structure as a collapsible tree:
Warehouse Connection
├── database_1
│ ├── schema_a
│ │ ├── table_orders
│ │ │ ├── order_id (INTEGER)
│ │ │ ├── customer_id (INTEGER)
│ │ │ └── order_date (DATE)
│ │ └── table_customers
│ └── schema_b
└── database_2
Navigation
- Expand/collapse databases, schemas, and tables
- Search to filter by name across all levels
- Column details show data type, nullability, and description
Databases, schemas, tables, and views are listed in plain alphabetical order regardless of how your warehouse happens to return them, so a schema named _staging sits with the underscores at the top instead of stranded at the bottom of a long list. Columns keep their real table order, because that is the order you expect to read them in.
Query a Table Without Writing the Query
Right-click any table or view and choose Select top 100 in editor. dbdeux opens a new worksheet already containing a row-limited select against that object, written in the dialect of that connection, ready to run.
It is the first thing anyone does with an unfamiliar table, and doing it by hand means remembering the fully qualified name, the right limit keyword for that warehouse, and getting the quoting right. This is one click instead.
Drag and Drop
Drag any object from the tree directly into the SQL editor:
- Drag a table to insert the fully qualified table name
- Drag a column to insert the column name
- Drag multiple columns to build a SELECT list quickly
Automatic Introspection
dbdeux automatically introspects your warehouse schema:
- On project creation to immediately populate the tree
- After each dbt run to reflect any schema changes
- On save/test to keep the tree current during development
- On demand via the refresh button
A running indicator shows when introspection is in progress. The tree remains interactive during updates.
Manual Introspection
Click the refresh button to trigger a full re-introspection. The process runs asynchronously in the background so it never times out, even on large warehouses:
- A confirmation dialog explains what will happen and how long it may take
- Progress polling with exponential backoff keeps the UI responsive
- A long-running hint appears if introspection takes more than a few seconds
- Once complete, the tree auto-expands to show new or changed schemas
- Scroll position is preserved so you do not lose your place
Every connection also has an always-visible refresh button on its row in the Databases list, so you can re-introspect a single connection without opening it first. The same confirmation dialog appears, so a full re-crawl is never triggered by an accidental click.
Two Kinds of Refresh in the Editor
In the editor's Databases panel, the refresh control offers both options explicitly, because they answer different questions:
| Option | What it does | Use it when |
|---|---|---|
| Refresh from last scan | Re-reads what dbdeux already knows and redraws the tree instantly | You expanded something stale or just want the panel back in sync |
| Re-scan a warehouse | Goes back to the warehouse itself to pick up objects that did not exist at the last scan | A run just created a table, or someone added a schema outside dbdeux |
On the Databases page you can also re-scan a single schema instead of the whole connection: right-click any schema and choose to re-scan just that schema's tables, views, and columns. On a warehouse with hundreds of schemas, picking up one newly created table becomes a few seconds of work rather than a full crawl. If a scan of that connection is already running, dbdeux says so and asks you to let it finish rather than stacking a second scan on top of it.
A re-scan tells you it has started, keeps the panel usable while it works, and refreshes the tree automatically when it finishes, with a clear message if it does not. Large warehouses can take a while, so it is a deliberate choice rather than something the panel does silently on every click. This removes the most common piece of confusion in a warehouse browser: whether a table is genuinely missing or simply not scanned yet.
Resilient Crawling
Introspection handles large warehouses gracefully:
- Processes schemas in parallel for faster completion
- Column details are collected in bulk per schema rather than table by table, which cuts scan time substantially on wide Snowflake accounts
- If one schema fails, others continue unaffected
- Bounded queries prevent timeouts on very large databases
- Results are cached and incrementally updated
Workspace-Scoped Connections
Warehouse connections belong to the workspace they were created in, so each team sees only the databases relevant to them:
- A workspace filter at the top of the Databases page narrows the list to a single workspace, or shows all of them at once
- Every connection carries a workspace badge so you can tell at a glance where it lives
- New connections are stamped with the active workspace, and creating one while a workspace is filtered puts it straight into that workspace
- The workspace dropdown appears automatically whenever you belong to more than one workspace
- A connection whose workspace is no longer available is clearly marked rather than appearing to belong nowhere, so you can move or remove it deliberately instead of wondering why it is there
Connection Access Levels
Not every connection should be usable by everyone. Each connection has an access level that controls who can see and use it:
| Access level | Who can use it |
|---|---|
| Workspace members | Everyone the workspace is shared with can use the connection |
| Admins and owners only | Only you and organization owners/admins can see or use it, which is ideal for protecting production databases from accidental use |
| Private to me | Only you can see or use the connection |
Organization owners and admins can change the access level of any connection, not just the ones they created, so a production warehouse can be locked down without hunting for whoever first added it.
Access levels hold when nobody is watching, too. A scheduled job or a CI run uses the connection on behalf of the person who set it up, checked against their real role in the organization, so a restricted production connection keeps working overnight for an admin's job and is still refused to someone who should not be able to reach it.
Preview Queries
Right-click any table to generate a preview query:
- Automatically uses the correct SQL dialect for your warehouse
| Warehouse | Preview Syntax |
|-----------|---------------|
| Snowflake |
SELECT * FROM table LIMIT 100| | BigQuery |SELECT * FROM table LIMIT 100| | Redshift |SELECT * FROM table LIMIT 100| | Databricks |SELECT * FROM table LIMIT 100| | StarRocks |SELECT * FROM table LIMIT 100| | PostgreSQL |SELECT * FROM table FETCH FIRST 100 ROWS ONLY| | Athena |SELECT * FROM table LIMIT 100| | MotherDuck |SELECT * FROM table LIMIT 100| | Microsoft Fabric |SELECT TOP 100 * FROM table| | Azure Synapse |SELECT TOP 100 * FROM table| | Fabric Lakehouse |SELECT * FROM table LIMIT 100|
Preview results appear in the results panel for quick inspection.
Brand Icons
Each connection displays its warehouse brand icon (Snowflake, BigQuery, Redshift, Postgres, Databricks, Athena, MotherDuck, Microsoft Fabric, Azure Synapse, StarRocks) for quick visual identification when working with multiple connections.
Connection Status
The status bar shows the current connection state:
- Connected (green) with the active database and schema
- Reconnecting (yellow) during temporary interruptions
- Disconnected (red) with clear error messaging