Exporting data

You can export a whole table, a table as the data grid shows it, or the result of a query. All three use the same dialog.

• A table — right-click it, or use Table → Export as CSV/JSON with the table tab open.
• What the data grid shows — Export view in the grid toolbar: the current filter and sort, or just the rows you selected. See Exporting from the data grid.
• A query result — Export Results in the SQL editor. Because results are cached, the export does not re-run the query. See Exporting a query result.

Formats

Format	Notes
CSV	Delimiter defaults to a comma
TXT	Delimiter defaults to a tab
JSON	Array of objects
XLSX	Excel workbook
ODS	OpenDocument spreadsheet
XML	One element per row
SQL	INSERT statements — structure only, or structure and data

Pick the format, set the file path, click Export. The dialog reports where the file was saved and — except for a whole-table SQL export — how many rows went into it.

Exporting from the data grid

Export view in the data grid toolbar exports the table the way you are looking at it: the filter, the column filters, the search box and the sort all apply. The dialog lists the filter and the sort it is going to use, so you can check them before exporting.

Under What to export:

Option	What goes into the file
All rows matching the filter	Every row the filter matches — the whole table, not just the loaded page — read from the server in the grid's sort order. Called All rows when no filter is applied
Selected rows only	Only the rows you selected in the grid. Offered only when rows are selected, and then chosen by default
Visible columns only	Leaves out the columns hidden with Columns. Offered only when some are hidden; on by default

To select rows, click a row number; Shift+click another row number to extend the selection to everything in between. Clicking the same row number again clears the selection.

Selected rows are written as the grid holds them

The selected rows come from the loaded page, not from a new read of the table. So:

• unsaved edits are not in the file, and neither are new rows that have not been saved yet — press Ctrl+S first;
• binary columns are <binary N bytes> placeholders in the grid, and that is what the file gets. For the real content use All rows matching the filter in SQL format, with a filter that picks the same rows — it writes binary columns byte for byte as hex literals. The text formats keep the placeholder.

In the SQL format you also set the Table name in INSERT statements — the current table by default; change it to load the rows into another table. With All rows matching the filter, Include structure (CREATE TABLE) puts the table's definition ahead of the INSERTs. Foreign keys and triggers are left out, because the file holds only part of the rows — for a complete copy of a table use Dump SQL file, described below.

Exporting a query result

Export Results in the SQL editor writes the result that is on screen — with several statements, the one whose tab is selected. The rows come from the result cache in the order the result grid is sorted, so what you see is what you get, without running the query again.

It always writes the whole result: selecting rows in the result grid does not narrow it down. To export only some rows, narrow the query itself (WHERE, LIMIT) and run it again.

In the SQL format, Table name in INSERT statements is filled in with the table the query reads from when NabuSQL can tell which one it is, and query_result otherwise.

SQL exports

Exporting a whole table as SQL has one extra choice: DDL only or DDL + data. DDL only gives you the CREATE TABLE statement, which is what you want when moving structure to another environment.

For a whole database, the sidebar has a faster path: right-click the database → Dump SQL file ▸ Structure and data or Structure only. The same submenu exists on a single table and on a selection of tables, which go into one file. Dumps work on MySQL, MariaDB, PostgreSQL, SQL Server and SQLite.

What a dump contains

Each table's structure — columns and types, defaults, primary and unique keys, checks and indexes — then its rows, then its triggers. The order inside the file is chosen so it restores cleanly:

1. the tables and their rows;
2. the foreign keys, after every table exists, so the tables can load in any order;
3. in a dump of the whole database, the functions, procedures and views — views in dependency order, so a view built on another view comes after it;
4. the triggers, last — created earlier, they would fire on every restored row and change the data on its way in.

Per engine:

Engine	Also in the dump
MySQL / MariaDB	SHOW CREATE TABLE as the server reports it, with a NEXTVAL default pointing at the sequence of whichever database the file is restored into; binary columns as hex literals (X'…'), byte for byte; triggers in DELIMITER ;; blocks with their firing order and sql_mode. A whole-database dump on MariaDB starts with its sequences, set to continue where the source stood
PostgreSQL	Serial sequences and identity columns — they continue after the highest restored value — generated columns, enum types and domains the table uses, comments, trigger functions, disabled triggers stay disabled
SQL Server	Schemas, IDENTITY with its seed and increment, computed columns, column collations, filtered indexes with INCLUDE; batches separated by GO
SQLite	The table as stored in sqlite_master, its indexes and triggers

Generated, computed and rowversion columns are left out of the INSERTs — the server fills them in.

Views, procedures and functions are in a dump of the whole database — right-click the database, or Backup — but not in a dump of selected tables. On PostgreSQL that includes materialized views (with their indexes, filled at restore) and view options such as security_barrier; objects that belong to an extension are left to CREATE EXTENSION. MySQL events are not dumped. Routines whose source is hidden — encrypted on SQL Server, or not visible to your MySQL account — are listed as a comment instead.

Restoring over existing tables

Each table is dropped before it is created. On PostgreSQL that is DROP TABLE … CASCADE, and on SQL Server foreign keys pointing at the table are dropped first — so restoring part of a database removes foreign keys from tables that are not in the file. A full backup puts every key back.

Dumping a sample of the data

Structure + Sample Data… in the same submenu writes the full structure but only some of the rows — enough for a test or development database, without copying production.

Option	Effect
Rows per selected table	How many rows each selected table contributes (default 100)
From the start / From the end	The first or the last rows by primary key. From the end with 100 gives the 100 most recent rows when the key is an auto-increment ID
Include related rows from parent tables (foreign keys)	Also export every row the sample points at (on by default)

Tables without a primary key are marked ⚠ — their rows come in whatever order the server returns them, so "the last 100" is only as meaningful as that order.

Related rows

With Include related rows on, the sample stays consistent: 100 order items bring the orders they belong to, those orders bring their customers, the customers their cities. The chain is followed as far as it goes, including a table that points at itself, and parent tables you did not select are added with just the rows that are needed. The window lists them before you export, with the table that pulls each one in.

Rows are never pulled the other way: a sampled customer does not bring all of its orders, otherwise a sample would grow towards the whole database.

The number of rows is therefore N per selected table, plus what the keys need. After the export a table shows how many rows each table got and how many of them came in through a key. The file restores with every foreign key in force.

Dumping vs backing up

Three things overlap here, so:

• Export — one table or one result set, in any of the formats above. For handing data to a person or another system.
• Dump SQL file — a .sql file with CREATE/INSERT statements for a table or a whole database, straight from the sidebar.
• Backup and restore — a full database dump with a progress bar, plus the restore side with error handling. For actual backups.

Moving data to another server

If the destination is another database rather than a file, do not export and re-import — Data transfer copies tables, views and routines directly between connections, including across different engines.