Exporting a Redshift query to Excel looks like a solved problem — until someone opens the file and asks why the invoice number lost its last five digits, why the timestamp moved eight hours, and why there are seventeen sheets instead of one.
None of those are bugs in the query. They are what happens when data that is wider than Excel meets Excel. This article shows the boundaries with numbers measured on a real export run.
1. What was measured, and with what
Excel is the same destination whatever the source is, so the limits below are properties of the Excel writer, not of Redshift. To keep the test reproducible we ran the export against a local PostgreSQL 15 database using Redshift’s data types (numeric(38,10), timestamptz, boolean, varchar(65535)), which is the same type family Redshift exposes).
Two notes on the test itself, because they matter if you try to repeat it:
- The Redshift provider in this product refuses a PostgreSQL server on purpose (it validates the
server banner: “PostgreSQL servers are not supported”). It was measured against a PG source with the PostgreSQL provider — the file writer, which produces the limits below, is the same code path.
- While testing we found that the command line could not connect to Redshift at all: the loader
builds its session file by hand and never wrote the Endpoint key the Redshift logon option reads, so it failed with "" is an invalid integer. Fixed in the build dated 2026-11-08.
Environment: Windows, PostgreSQL 15.1 on the same machine, Excel writer of DBToFile.
2. The sheet split: 65,536 rows per sheet
Excel 2007 and later support 1,048,576 rows per sheet — but the writer splits at the older 65,536-row boundary, which is what Excel 97–2003 supported.
| Rows exported | Sheets produced | Rows per sheet |
|---|---|---|
| 200,000 | 4 (events, events_2, events_3, events_4) |
65,535 + header |
| 1,100,000 | 17 | 16 × 65,535 + 51,440 |
So a 1.1-million-row pull arrives as seventeen worksheets, each headed with the same column names. That is often exactly what you want (a pivot source that fits in memory), but it is a surprise if you expected one sheet and wrote a formula that references it by name.
Two practical consequences:
- Any downstream formula must union the sheets.
events!A:Aonly sees the first 65,535 rows. - The split is by row count, not by key. If the sort order changes between exports, the same
record can land on a different sheet.
3. numeric(38,10) is not a number Excel has
Excel stores every number as a double: 15 significant digits. A Redshift numeric(38,10) keeps 38 digits. The conversion is silent — no warning, no error, just digits that are no longer there.
Measured on the same export:
Value in Redshift (numeric(38,10)) |
Value in the cell |
|---|---|
1.0000000001 |
1.0000000001 (fits) |
12345678901234567890.1234567890 |
1.23456789012346E+19 (only 15 significant digits survive) |
9999999999999999999999999999.9999999999 |
1E+28 |
0.0000000001 |
1E-10 |
What this means in practice:
- Amounts with cents are fine (
numeric(12,2)is well inside 15 digits). - Ids, hashes, bank accounts and long decimals are not. If a column identifies something rather
than measuring it, export it as text: cast it in the query (id::text) before it becomes a cell.
- Excel also drops trailing zeros, so
1.10and1.1are the same cell. Reports that need two
decimals must format the column afterwards.
4. timestamptz becomes local wall-clock time
A Redshift timestamptz (or PG timestamptz) carries an offset. Excel cells carry a date and a time and nothing else. The writer converts to the machine’s local time zone and drops the offset:
| Stored value | Cell content |
|---|---|
2024-03-01 00:00:00+00 |
2024-03-01 08:00:00 (machine is at +08:00) |
2024-03-01 12:00:00+08 |
2024-03-01 12:00:00 |
2024-07-01 00:00:00+00 |
2024-07-01 08:00:00 |
If the workbook is opened on a machine in another time zone, the numbers no longer mean the same instant. For anything with an audit trail, either export to_char(ts at time zone 'UTC', 'YYYY-MM-DD HH24:MI:SS') as text, or keep a separate UTC column.
5. boolean and NULL
booleanarrives as text —True/False— not as an Excel boolean.SUM()over such a
column returns 0; COUNTIF(range,"True") works.
NULLarrives as an empty cell, which is the same as an empty string in Excel.COUNTBLANK()
will count both, and =A1="" is true for both. If the difference matters, export a IS NULL flag column.
- Long text is preserved: a 2,000-character
varcharcolumn came through complete in the same
export (the 32,767-character cell limit is the one to watch; anything above that is truncated).
6. What it costs
| Table | Rows | Columns | Time | File size |
|---|---|---|---|---|
events |
200,000 | 6 (incl. numeric(38,10), timestamptz, boolean, 2,000-char text) |
9.6 s | 7.3 MB |
events_big |
1,100,000 | 2 | 21.0 s | 16.9 MB |
Both are local-to-local on a laptop-class machine; a networked Redshift will add transfer time, and the xlsx writer is CPU-bound, so expect the file side to dominate on wide tables.
7. When Excel is the wrong destination
- Above ~1 million rows you get a sheet split, which is fine for analysis but painful as a
deliverable. CSV has no such limit (one file, 1.1M rows, no splitting).
- When the values must stay exact (ids, money with more than 15 digits, timestamps with an
offset), Excel cannot hold them. CSV or a database-to-database copy can.
- When it is a recurring job: schedule the export and let it overwrite the same file, rather than
keeping a manual “export 2026-11-08 final v3.xlsx” collection.
8. Verifying an export before you send it
- Compare row counts per sheet with the source count; 17 sheets of 65,535 means the split ran.
- Check one id column for a value with more than 15 digits — if it shows as
1.23E+19, the column
should have been text.
- Open a timestamp cell and compare it with the stored value; if they differ by whole hours, the
offset was dropped locally.
- Search for
TRUE/FALSEas text in a boolean column, and decide whether the report needs real
booleans (it usually does not, but filters do).
- Check the last sheet — the final partial sheet is where a truncated export shows up first.
9. Doing it without a script
The direct pair page Redshift to Excel runs the export locally (no data leaves the machine), and Excel to Redshift does the reverse. For a scheduled pull, the same GUI session can be saved and run from the command line.
FAQ
Why did my export produce multiple sheets?
The writer splits at 65,536 rows per worksheet (the Excel 97–2003 limit). 1,100,000 rows becomes 17 sheets: sixteen full ones plus a partial last sheet.
Why did a long number lose digits?
Excel stores numbers as doubles: 15 significant digits. A numeric(38,10) value with more digits is rounded silently. Cast identifier-like columns to text in the query.
Why did the timestamps shift by a few hours?
timestamptz was converted to the machine’s local time zone and the offset was dropped. Export a UTC string if the workbook has to be time-zone independent.
Are booleans real booleans in the file?
No — they arrive as the text True / False. Numeric aggregation over them returns 0.
How do I keep leading zeros (zip codes, account numbers)?
They are numbers to Excel and lose the zeros. Export them as text (lpad(zip::text, 5, '0')) or prefix with '.
Does the cell limit matter?
Excel caps a cell at 32,767 characters. A 2,000-character text column is safe; a 50,000-character document field will be cut.
Can the export be scheduled?
Yes — save the session in the GUI and run it from the command line on a schedule. The CLI reads the same session file.
Is CSV better for big pulls?
For anything above ~1M rows or with values that must stay exact, yes. CSV keeps every digit and does not split; Excel is for the reader, not for the data.
Measured 2026-11-08 against PostgreSQL 15.1 (Redshift type family) on a local machine, exporting with DBToFile. Row limits, numeric rounding and time-zone behaviour are properties of the Excel writer and were read back from the produced workbook, not taken from documentation. The Redshift provider validates the server banner and refuses PostgreSQL, so the Redshift handshake itself was not exercised here; the command-line Endpoint defect found during this test was fixed the same day.
Redshift → EXCEL reference
Type mapping
| Value kind | in Redshift | in EXCEL |
|---|---|---|
| Int | integer | 1234 (a real numeric cell) |
| Bigint | bigint | 9007199254740993 (exact only while the cell stays text) |
| Decimal | numeric(p,s) | 1234.56 (numeric cell, format controls the displayed decimals) |
| Float | double precision | 1.234E+10 (numeric cell) |
| Text | varchar(n) | text cell; leading zeros survive only if the column is text |
| Long text | varchar(max) | text cell; wraps inside the cell rather than the row |
| Date | date | a serial number plus a date cell format |
| Datetime | timestamp | a serial number plus a date-time cell format |
| Binary | (none) | not representable as data |
| Boolean | boolean | TRUE / FALSE (a real boolean cell) |
| JSON | super | a text cell; the quotes are part of the value |
Dialect differences
Redshift is a database server and EXCEL is a file format, so the gap is wider than a dialect difference - the rows below are where values and structure stop lining up.
| Property | in Redshift | in EXCEL |
|---|---|---|
| port | 5439 | — |
| identifiers | "double quotes" | Not applicable; a cell holds exactly one value |
| row limit | LIMIT n | — |
| dates | timestamp, date | Stored as a serial number; only the cell format makes it lo... |
| long text | VARCHAR(MAX) | — |
| binary | — | Only as text or an embedded object, not as a data column |
| separator | — | Cells, not delimiters |
| encoding | — | UTF-8 internally, declared in the package |
| typing | — | Real cell types: text, number, date, boolean, error |
| shape | Tables of rows and columns | Multiple sheets, each a flat grid |
| ceiling | — | 1,048,576 rows x 16,384 columns per sheet; 255 sheets per w... |
Command line
| Side | Command |
|---|---|
| Redshift | UNLOAD to S3 |
| Redshift (load) | COPY from S3 |
No counterpart
- EXCEL has no equivalent for Binary - it has to be flattened or dropped.
DBCopier without the manual work
For batch jobs, large files and scheduling use the DBCopier converter — an offline desktop app for Windows, Linux and macOS. Free trial.