Exporting results
Requires Pro (ExportData). See
Plans and Pro features.
Export writes the whole result of your query to a file — not the part the grid has scrolled to.
It re-runs the query
Export runs the last executed query again, into a separate result, and writes all of it. The grid's cursor is untouched, so exporting does not disturb what you are looking at, and the file does not stop at whatever number of batches you happened to have fetched.
Export is available for read-only results too. Reading a result is not editing it.
The file describes the database, not your unsaved edits
Export writes what the query returns. Pending edits in the grid are a draft and are not part of the query's answer. Save them first if you want them in the file.
Formats
| Format | Notes |
|---|---|
| BSON | The documents as MongoDB stores them. Lossless |
| JSON | Canonical MongoDB Extended JSON, one document per line. Lossless |
| CSV | Cells carry Extended JSON — see below |
CSV keeps Extended JSON inside the cells, because bare CSV cannot tell a date from text that looks like one. The header is the union of the fields of all documents, and a field a document does not have is left empty with no quotes — which is how the file distinguishes no field from empty string.
Both the collection export and the result export write through the same writer, because the import path reads these files back. A second writer that drifted would produce files the application cannot read.
Excel and SQL INSERT output are not available. They are tracked as open
work; there is no date.
Large results
Rows are transformed while the file is written rather than collected first. Reading a row decodes it, and transforming it builds a payload and a document on top of that, so collecting everything first made the result exist in memory three times before a single byte reached disk. Measured on ten thousand wide records: 1,037 ms and 67 MB still live at the end, for an 18 MB file. Streaming it: 359 ms and 2 MB.
CSV needs its header before the first row, and in a schemaless database a late batch can introduce a new field. So a CSV export streams the full result to a temporary BSON file while collecting column names, then reads it back into the final CSV. That is two I/O passes, and still one batch in memory with a complete header.
A query shape the engine cannot stream yet, and which would exceed the safe materialisation limit, is refused. TableCore does not quietly write the first ten thousand records, and does not lift the limit at the cost of several gigabytes of RAM.
A failed export leaves nothing
A file that looks like a complete result and is truncated is worse than no file. A row that cannot be transformed is detected during writing, and the partial file is deleted.
Types on the way out
Typed cells return to BSON through the same normalisation path a document save
uses. There is exactly one place that builds the typed-value marker; a second
implementation could drift, and for this model drifting means quietly writing a
string where an ObjectId or a date belongs.