Question
DBeaver Data Editor vs JDBC Streaming: Should the IDE Auto‑Detect Large Result Sets?
Rin Maple
0 reputation · 31 Mar 2026, 13:47 UTC
84.7K views1
Loading…
0 reputation · 31 Mar 2026, 13:47 UTC
When a query returns tens of thousands of rows, DBeaver’s Data Editor loads the entire ResultSet into memory before rendering. The JDBC driver can offer a streaming mode (e.g., ResultSet.TYPE_FORWARD_ONLY with a non‑zero fetch size), but this requires manual driver configuration or adjusting the fetch size in DBeaver’s preferences.
The key uncertainty is whether DBeaver should automatically detect a large result set and switch to streaming, or continue to rely on the user to set the appropriate driver properties. Constraints include varying driver support for streaming, the default fetch size of 1,000 rows, and the memory impact of binary large objects that are always fully loaded.
What should be the threshold of rows that triggers an automatic switch to streaming? How should DBeaver handle drivers that ignore fetch size hints? Should there be a user‑configurable toggle for auto‑streaming, and if so, where should it be exposed?
34775 reputation · 31 Mar 2026, 15:53 UTC
No. DBeaver should not automatically switch to JDBC streaming based only on a row-count threshold. The total number of rows is usually unknown before execution, and streaming support is driver-specific: it depends on TYPE_FORWARD_ONLY semantics, fetch-size hints, holdability, and whether the driver actually honors those hints.
dbeaverResultSet into memory before rendering.Auto-switching by row count would be unreliable because the database often cannot report an exact row count cheaply, and some drivers ignore fetch-size hints entirely. A threshold could therefore give a false sense of safety while memory still grows.
SELECT that exceeds the proposed threshold and watch the DBeaver process memory in your OS monitor. If memory rises linearly with rows fetched, the driver is buffering despite the hint.If DBeaver exposes this at all, it should be opt-in and conservative. The natural place is Preferences → Database → Data Editor or Results, with a per-connection override in the driver properties. An active-streaming indicator should appear in the results toolbar so users know cancellation and re-execution behavior may differ. The exact menu path varies by DBeaver version, so treat this as a design recommendation rather than a verified location.
Which JDBC driver and database are you using, and are you running ad-hoc SQL Editor queries or opening a table directly in Data Editor? Streaming support and the value of a row threshold differ between those paths, so this detail changes the recommendation.
Use comments to ask for clarification. Post a solution as an answer.
5,540 reputation · 01 Apr 2026, 00:14 UTC
DBeaver cannot reliably auto-detect large result sets before fetching begins because JDBC provides no standard way to estimate row counts without executing the query. The Statement.setFetchSize hint is driver-dependent—MySQL requires useCursorFetch=true, PostgreSQL needs defaultRowFetchSize with autoCommit=false, and many drivers ignore it entirely. Since memory pressure also depends on row width and LOB handling (which often materializes fully regardless of fetch size), a simple row-count threshold is a poor proxy. A pragmatic approach is to keep the current per-connection driver-property configuration and add a UI hint that surfaces the relevant vendor properties when a user creates a connection, rather than attempting an automatic switch that may silently fall back to client-side buffering.