DBeaver slow with big results? A native client

To be clear: this post is not a dunk. DBeaver is a genuinely useful tool and its Community edition is real open source, and I keep an honest comparison page that says so. But if your day is long analytical queries and million-row exports, the architecture question stops being academic. It's worth understanding why a Java-based client struggles before you decide what to run instead.

Why Java-based clients get heavy on big data

A Java IDE-style application runs inside a JVM with a managed heap. Every cell of every result set you hold in memory is a managed object, and the garbage collector has to keep up with all of it. When a query returns hundreds of thousands of rows, three costs stack up:

• Memory: rows buffered as Java objects cost far more than the raw bytes on the wire.
• Collection pauses: when the heap fills, the JVM stops the world to tidy up, and your UI stops with it. This is the coffee break Eclipse users know by heart.
• UI contention: database work and interface rendering compete for attention, so a heavy query is felt in every click that follows.

On top of that sits JDBC: a driver layer that reads result sets on its own terms, not the grid's. The grid, the driver and the collector each keep their own copy of your data. That's the tax you pay on every large result, whatever database is on the other end.

What a native engine does differently

SQLly is built in Rust and renders its interface directly on the GPU (Metal on macOS, Direct3D on Windows, Vulkan on Linux). There is no JVM and no Eclipse platform underneath. That alone changes the feel of the app, but the part that matters for big results is deeper: SQLly speaks each database's wire protocol itself: TDS for SQL Server, the PostgreSQL and MySQL protocols, ClickHouse's HTTP interface, libSQL's Hrana, Redis's RESP, with SQLite and DuckDB running in-process, in a dedicated engine that runs off the UI thread.

Rows stream through a bounded channel with real backpressure: if the grid cannot keep up, the engine waits instead of buffering. Past a threshold, results spill to disk and the grid pages from the file. The practical upshot, which I walk through in streaming huge result sets without eating your RAM, is that a 50-million-row result behaves like a small one: you get the first rows fast, you can scroll to the end, and your laptop fan stays quiet.

Test it on your own queries

Don't take my word for it, benchmark switching is cheap. Pick a query you actually run, ideally one you avoid because it is slow, and run it in both tools. Something like this, on any PostgreSQL instance with real data:

SELECT o.customer_id,
       count(*)                AS orders,
       sum(o.total_amount)     AS revenue
FROM   orders o
JOIN   customers c ON c.id = o.customer_id
WHERE  o.created_at >= now() - interval '90 days'
GROUP BY o.customer_id
ORDER BY revenue DESC;
-- the comparison that matters is time-to-first-rows, not just total time

Measure three things in each tool: how long until the first rows appear, how long until the grid is fully scrollable, and what your machine's memory does while the result is open. The third number is usually where Java clients and native ones part ways.

You can even skip the install for a first look: the live preview runs the real SQLly workbench compiled to WebAssembly, in your browser, against sample databases, no account needed.

To be fair: reasons to stay on DBeaver

The switch isn't for everyone, and I'd rather say so than win a click:

• You need open source. DBeaver Community is Apache 2.0 licensed and you can read every line. SQLly is proprietary (its lifetime license carries a source-escrow promise instead).
• You need the very widest engine list today. DBeaver connects to almost anything through JDBC. SQLly covers 30 engines: SQL Server, PostgreSQL, MySQL and SQLite families, DuckDB, ClickHouse, Oracle, libSQL/Turso, Redis. But connectors for Db2, Snowflake and Databricks are on the roadmap, not shipped.
• You rely on Eclipse-plugin tooling. If your workflow runs on DBeaver's project and script ecosystem, replatforming costs more than it returns. That's just math.

Getting started

1. Download SQLly for macOS (Windows and Linux builds are in supported beta).
2. Re-add your connections: it takes minutes, and your SQL files carry over as files.
3. Run the benchmark query above and compare the three numbers.

And if you want the full feature-by-feature rundown first, it lives on SQLly vs DBeaver.