Question
DBeaver Data tab row fetch limits and low-traffic workload cost tuning
Nia Cedar
0 reputation · 01 Sept 2023, 14:10 UTC
95.8K views
Loading…
0 reputation · 01 Sept 2023, 14:10 UTC
For a low-traffic workload, tuning DBeaver's initial row fetch in the Data tab is intended to reduce client memory and database load, but the default and override behavior vary by database driver and edition. Identical tables may display different row counts across connections, complicating cost control.
Raising or disabling the fetch limit removes the safeguard that protects client and server resources, potentially increasing consumption on large tables and negating the intended low-traffic benefit. Applying filters or sorting issues a new query subject to the fetch limit, though the interaction between client-side paging and server-side fetch size remains version-sensitive.
Because preference labels and default values differ between DBeaver versions and database drivers, and the row limit controls display fetching rather than the total result set when a custom SQL query requests more rows, the boundary between display paging and server-side execution cost is not always clear.
What is the documented behavior for the Data tab row fetch limit when a filter or sort is applied, and does the limit apply uniformly across database drivers and DBeaver editions? How does client-side paging interact with server-side fetch size when the row limit is adjusted, and where is this interaction documented for a version? Is there a supported way to configure the initial fetch size for low-traffic cost tuning without disabling the resource safeguard?
33775 reputation · 01 Sept 2023, 19:53 UTC
When a filter or sort is applied in the DBeaver Data tab, the application re-executes the query against the database. This new request is subject to the Maximum rows to fetch setting. Consequently, the resulting view will only contain up to the limit defined in your preferences, regardless of how many rows matched the filter criteria in the total dataset.
The logic governing the row limit is consistent between DBeaver Community and Enterprise editions. However, the actual enforcement is not uniform across database drivers. DBeaver relies on the JDBC Statement.setMaxRows() method; some drivers implement this strictly via server-side LIMIT or TOP clauses, while others may fetch more rows than requested and truncate the result set on the client side. This explains why identical tables may exhibit different row counts across different connection types.
There is a critical distinction between the Maximum rows limit and the Fetch size:
If your maximum rows limit is 200 and your fetch size is 50, DBeaver will perform up to four network requests to fill the grid. Once 200 rows are reached, paging stops. This interaction is documented within the Preferences > Data Editor section of the DBeaver installation.
To reduce database load and client memory consumption without disabling resource safeguards, use a tiered approach to fetch settings rather than removing the limit entirely.
dbeaverPreferences > Data Editor > Maximum rows to fetch at a low value (e.g., 100–200). This ensures no single accidental click on a million-row table crashes the client or spikes server CPU.Fetch size (found in Connection Settings > Driver Properties) to a modest value (e.g., 50). This balances the number of network round-trips against the memory footprint per batch.To verify that your settings are active and not being overridden by the driver:
LIMIT or equivalent clause matching your "Maximum rows" setting.Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.