Query Execution #
Run a query with Cmd+Enter. SELECT executes the SQL against one or more associated databases and displays results in a table below the editor.
Streaming (proxified connections) #
When using proxified connections, results are streamed progressively. You see rows as they arrive instead of waiting for the full result set. The table fills incrementally while the query is still running.
For local connections, results are fetched in a single round-trip.
Limits #
Two settings in your .config file control execution bounds:
| Setting | Default | Max | Description |
|---|---|---|---|
| statement_timeout_ms | 30000 | none | Max query execution time (milliseconds) |
| max_result_size_mb | 100 | 250 | Max result size before truncation (MB) |
These limits apply to both local and proxified queries. When a timeout fires, SELECT cancels the query on the database side. If the result exceeds the size limit, it is truncated and a notice is shown.
Set statement_timeout_ms to 0 to disable the timeout entirely. This is useful for long-running migrations or bulk operations.
Proxified connections: limitations #
Proxified queries are executed on the remote backend and streamed back over HTTP. This introduces constraints that do not apply to local connections:
- 45-minute HTTP ceiling. Regardless of
statement_timeout_ms, the HTTP transport enforces a hard 45-minute timeout. Queries that exceed this are terminated. Settingstatement_timeout_msto0disables the query-level timeout but does not remove the HTTP ceiling. - No resume on disconnect. If the network connection drops mid-query (Wi-Fi change, NAT timeout, laptop sleep), the stream is lost. The query may keep running on the database, but SELECT has no way to reconnect and retrieve the results.
- Connection pool pressure. Each running query holds one connection from the backend’s pool for its entire duration. Long-running queries reduce the number of connections available to other users on the same datasource.
Long-running statements #
For operations that take more than a few minutes (migrations, bulk inserts, index rebuilds), connect to the database directly using its native client (psql, mysql, etc.) instead of running them through a proxified connection. Direct connections are not subject to the HTTP ceiling and survive transient network issues.
If you must run a long statement through SELECT, keep statement_timeout_ms high enough to cover the expected duration and ensure your network connection is stable for the entire time. There is no progress indicator for DDL statements that return no rows.
Result caching #
Results are cached on your machine. Switching tabs and coming back shows the cached result instantly without re-executing. Running the query again replaces the cache.