DBeaver Data Transfer Wizard: practical cross-database migration for DBAs

Why bulk data migration hurts

Moving millions of rows between databases is a routine yet fragile task. DBAs often resort to dump‑and‑restore scripts, CSV round‑trips, or custom ETL pipelines. Each approach carries risk: data type mismatches, silent truncation, or hours of manual verification. When the source and target use different SQL dialects, the complexity multiplies. The result is often a time‑consuming cycle of export, transform, import, and validate – with no built‑in safety net.

Takeaway: DBeaver’s Data Transfer wizard replaces much of this manual grind with a guided pipeline that handles filtering, type mapping and format conversion in one interface.

DBeaver’s Data Transfer wizard in focus

The wizard lives in the DBeaver UI under the “Data Transfer” action. It walks you through source selection, target configuration, and a preview step before any data moves.

Setting up source and target

• Source: pick any JDBC‑compatible database DBeaver already connects to. The wizard reads the schema and lists available tables.
• Target: you can choose another JDBC source (for live copy), or a flat‑file format such as CSV, Excel or JSON.
• SQL filter: enter a WHERE clause to pull only the rows you need. For example, WHERE created_at > '2024‑01‑01' limits the export to recent records. The wizard validates the syntax against the source dialect when possible.
• Batch size: controls how many rows are fetched per round. The default may be large; on memory‑constrained machines, lowering it to 50 000 or 100 000 prevents JVM out‑of‑memory errors. This setting lives in the wizard’s “Advanced options” panel.
• Row preview: before execution, DBeaver shows the first N rows. This is a quick sanity check that the filter and column mapping are correct.

Choosing output format

• CSV: widely supported, easy to load into BI tools or downstream scripts.
• Excel (.xlsx): handy for stakeholders who need formatting without writing formulas.
• JSON: useful for API‑driven downstream processes or NoSQL ingestion.
• JDBC target: pipe the result set directly into another table, with column‑level mapping if schemas differ.

The wizard also offers a “compress output” toggle for CSV and JSON, reducing disk footprint at the cost of a modest CPU overhead.

Worked example: 2 M PostgreSQL rows to CSV

1. Open DBeaver, connect to the PostgreSQL database.
2. Right‑click the database (or schema) and select “Data Transfer”.
3. In the “Source” panel, ensure the correct database is selected. Click “Next”.
4. In the “Target” panel, choose “CSV file”. Browse to a writable location, enable “Compress output”, and set the “Batch size” to 50 000.
5. Click the “Filter” tab and enter WHERE customer_id > 0 – or a more selective predicate if you only need a segment.
6. Hit “Preview”. DBeaver displays the first few rows with column types. Verify that the WHERE clause behaves as expected.
7. Click “Transfer”. The wizard streams rows in batches, writes the CSV, and finishes with a summary log that includes total rows written, skipped rows (if any), and elapsed time.

The log’s “throughput” field (rows per second) and “skipped rows” count let you validate completeness without manually counting records. If the file size seems unexpectedly small, check the batch setting or the filter predicate.

Important: I am not claiming this exact run was executed or timed. The steps describe the feature’s workflow as documented in the feature set.

Trade‑offs you should weigh

The wizard’s greatest strength is convenience. You get a graphical interface, built‑in filtering and format conversion without writing a single line of code. For routine migrations, ad‑hoc exports, or moving data between environments with similar schemas, this speeds up the cycle considerably.

However, three practical limits are worth noting:

• Memory pressure: the default batch size can load too many rows into the JVM heap at once. If you see java.lang.OutOfMemoryError, reduce the batch size or close other DBeaver tabs to free heap.
• Disk I/O: exporting 2 M+ rows to an uncompressed CSV can generate hundreds of megabytes or gigabytes. On a busy server, this may contend with other processes. Compressing the output mitigates size but adds CPU load.
• Performance gap: for highly tuned workloads – say, extracting a precise subset with complex joins – a hand‑crafted JDBC script can run faster because you control fetch size, streaming libraries, and parallelism. The wizard abstracts these knobs, which is good for most users but limits fine‑grained optimization.

In practice, use the Data Transfer wizard for quick cross‑platform moves and script‑based pipelines when performance is the overriding concern.

Quick verification checklist

1. Run the wizard on a test database with a narrow filter, e.g., SELECT * FROM orders WHERE order_id < 100.
2. Export to CSV and open the file in a spreadsheet or text editor.
3. Count the rows; they should match the expected number (99, if the filter starts at 1).
4. Compare the transfer time with a minimal JDBC snippet that executes the same query and writes to a file. Note the difference; a larger gap may indicate the wizard’s overhead for your data volume.

These checks take under five minutes and give you confidence before scaling up to production‑size exports.

When to reach for a script instead

If your migration involves terabytes of data, requires custom transformations (pivoting, aggregations, or type casting that the wizard doesn’t support), or must fit within a strict SLA, a dedicated ETL tool or a hand‑rolled JDBC/ Python script may be more appropriate. The Data Transfer wizard excels at the “move‑and‑verify” phase of a broader pipeline, not at replacing a full‑featured data integration platform.

By understanding both the wizard’s capabilities and its boundaries, you can decide faster whether to click through the GUI or open a code editor – and either way, you’ll spend less time wrestling with spreadsheets and more time on high‑value database work.