Exporting Tables and Query Results to CSV in DBeaver: A Practical Configuration

If you need a table or query result out of a database and into a spreadsheet, script, or ticket attachment, DBeaver's built-in Export Data wizard does the job without any plugins. The short version: right-click the table or result set, choose Export Data, pick CSV, enable the header row, set the delimiter to comma, the quote character to double quote, and the encoding to UTF-8. That combination survives Excel, pandas, and most CSV parsers without surprises.

The rest of this article explains why those settings matter, walks through one concrete configuration, and covers the limits that bite people on large or unusual data.

How the export actually works

DBeaver's CSV export is client-side. DBeaver runs your query (or a SELECT * against the table) through the JDBC driver, reads the result set row by row, and formats each value as text on your machine. Nothing happens on the database server — there is no COPY or SELECT INTO OUTFILE equivalent involved, even if your database has one.

This has two practical consequences. First, export speed is bounded by your network round trips and DBeaver's fetch settings, not by server disk speed. Second, the values you get are whatever the JDBC driver hands DBeaver, formatted by DBeaver's data-type handlers — which matters for dates, decimals, and binary columns.

A configuration that round-trips cleanly

Start the wizard one of two ways:

• Right-click a table or view in the Database Navigator and choose Export Data.
• Run a SQL query in the editor, then right-click inside the result grid and choose Export Resultset (the exact label varies by version). Exporting from a result set is usually the better habit, because the query pins down exactly which columns and rows you get.

In the wizard, use these settings:

Finish the wizard and DBeaver writes the file. No database state changes — this is a read-only operation, so there is nothing to roll back.

Verify the output before sending it anywhere

Don't trust the wizard's success dialog as proof the file is correct. A two-minute check catches the common failures:

1. Create or pick a small test table containing a text value with a comma in it, a numeric value, a real NULL, and a non-ASCII string (for example José).
2. Export it with the configuration above.
3. Open the .csv in a plain-text editor — not Excel, which hides quoting and reinterprets values. Confirm: the first line is the column names; the comma-containing value is wrapped in double quotes; the row count matches the source; José is still readable (if it shows as mojibake, the encoding was wrong).
4. For anything important, re-import the CSV into a scratch table or load it with pandas (pandas.read_csv) and compare row counts and a few spot values against the original query.

Limits and common mistakes

NULLs don't round-trip by default. A SQL NULL is exported as an empty field, which is textually identical to an empty string. If the distinction matters downstream, check the wizard for a NULL-value marker option (availability varies by version) or handle it in your query, e.g. COALESCE(col, '\N') — but document whatever convention you pick.

Binary and LOB columns are unreliable in CSV. Depending on the driver and settings, BLOBs may be truncated, hex-encoded, or exported as a placeholder. If you need binary data out, use a database-native dump tool instead.

Very large exports are slow and memory-hungry. Because everything flows through the JDBC result set into DBeaver, exporting tens of millions of rows is much slower than a server-side tool like PostgreSQL's COPY ... TO or MySQL's SELECT ... INTO OUTFILE. For big one-off extracts, prefer the server-side tool; use DBeaver's export for result sets up to a few million rows where convenience outweighs speed.

Delimiter collisions. If you switch the delimiter to semicolon or tab but leave quoting off, any value containing that character silently corrupts the column layout. Keep quoting enabled regardless of delimiter.

Implicit column drift. Exporting via right-click on the table exports whatever columns exist at that moment, in table order. If the export feeds a repeatable process, write an explicit SELECT col1, col2, ... and export the result set instead, so schema changes can't silently reorder or add columns.

Version differences. Menu labels and available options differ between DBeaver Community and Enterprise editions and across releases. The settings above exist in current Community builds, but check the actual wizard pages in your installed version rather than assuming identical wording.

Making it repeatable

For exports you run regularly, keep the SQL in a saved script, reuse the same export settings each time (the wizard remembers recent choices), and write output to a dated filename. That gives you a stable, auditable extract without needing DBeaver tasks or the enterprise scheduler — though those exist if you outgrow the manual flow.