DEV Community

Arya Hegiste
Arya Hegiste

Posted on

Exporting DynamoDB Data Safely to CSV with Tables

#aws #database #serverless #tutorial

Exporting DynamoDB data to CSV sounds straightforward until the dataset contains values that spreadsheets interpret differently from plain text.

Formula-like strings such as =2+3, Unicode text, commas, quotes, embedded newlines, nested DynamoDB values, binary data, booleans, and nulls can all make a seemingly simple export more interesting.

In this walkthrough, I used Tables by Serverless Creed to export a controlled DynamoDB dataset to CSV and verified both the raw file and its behavior when opened in Microsoft Excel.

The goal was to answer a simple question:

Can a DynamoDB result be exported to CSV without losing its structure or allowing formula-like strings to execute unexpectedly in a spreadsheet?

Test setup
I created a disposable DynamoDB table named:

TC-EXP-002-Blog
Enter fullscreen mode Exit fullscreen mode

The table used a composite primary key:

PK  — String
SK  — String
Enter fullscreen mode Exit fullscreen mode

It was created in ap-south-1 using on-demand billing.

I inserted eight controlled items covering several CSV edge cases:

  • Formula-like strings such as =2+3, +1+2, @formula-test, and -10+5
  • Unicode text: नमस्ते 日本語 🚀
  • Commas inside values
  • Double quotes
  • An embedded newline
  • Nested maps and lists
  • A null value
  • Binary data
  • Numbers and booleans

AWS CLI verification confirmed that the table contained exactly eight items:

Count: 8
ScannedCount: 8
Enter fullscreen mode Exit fullscreen mode

Configuring the CSV export
From the table's data workspace, I opened Export and selected CSV as the output format.

The export review screen showed several useful details before any file was written:

Export mode: Streaming
Scope: All matching rows across all pages
Format: CSV
Privacy: Original values
File safety: Atomic replacement
Destination: Local file
Enter fullscreen mode Exit fullscreen mode

The interface also displayed an important spreadsheet-safety message:

Formula-like strings and column names receive a leading apostrophe.

This matters because applications such as Excel can interpret values beginning with characters such as =, +, -, or @ as formulas rather than ordinary data.

Inspecting the raw CSV first
After exporting the eight rows, I deliberately inspected the CSV as a raw text file before opening it in Excel.

This is an important verification step. A spreadsheet application can transform or interpret CSV values while opening the file, so looking only at Excel does not necessarily tell us what the exporter actually wrote.

The raw file contained entries such as:

'=2+3
'+1+2
'@formula-test
'-10+5
Enter fullscreen mode Exit fullscreen mode

The leading apostrophe was present in the exported data.

That means the current export successfully neutralized the formula-like strings before they reached the spreadsheet.

The raw CSV also preserved the Unicode value:

नमस्ते 日本語 🚀
Enter fullscreen mode Exit fullscreen mode

Other edge cases were visible as well.

A value containing quotes was CSV-escaped appropriately, while comma-containing values were quoted. The embedded newline remained part of its quoted CSV field.

Nested DynamoDB data was serialized into string representations suitable for the flattened CSV format.

Binary data containing Hello appeared as:

`SGVsbG8=`
Enter fullscreen mode Exit fullscreen mode

The null attribute was represented as an empty CSV field.

Opening the export in Excel
I then opened the same CSV file directly in Microsoft Excel.

The most important result was that the formula-like values were no longer executed.

Instead of:

=2+3 → 5
+1+2 → 3
-10+5 → -5
Enter fullscreen mode Exit fullscreen mode

the exported values remained text.

This confirms that the spreadsheet-safety transformation visible in the raw CSV prevented these values from being evaluated as formulas in this test.

Numbers and boolean values were also retained, and the CSV structure remained readable.

One important Unicode observation
There was, however, a difference between the raw file and Excel.

The raw CSV contained the expected Unicode text:

नमस्ते 日本語 🚀
Enter fullscreen mode Exit fullscreen mode

When I opened the CSV directly in my Excel environment, that text displayed as garbled characters.

This distinction is important.

The raw-file inspection showed that the Unicode data existed correctly in the exported file. Therefore, the evidence from this test does not show that Tables destroyed the Unicode value during export.

Instead, the issue appeared during the way this Excel environment interpreted the CSV when opening it directly.

This is exactly why checking both the raw output and the spreadsheet representation is useful.

Testing export failure and recovery
I also wanted to verify what happened when the destination itself was invalid.

During another export, I deliberately entered the following Windows filename:

TC-EXP-002:invalid.csv
Enter fullscreen mode Exit fullscreen mode

Because : is not permitted in a normal Windows filename, the operating system rejected it with:

The file name is not valid.
Enter fullscreen mode Exit fullscreen mode

The invalid destination therefore did not produce a final CSV presented as a successful export.

I then corrected the destination to:

TC-EXP-002-Blog-Recovery.csv
Enter fullscreen mode Exit fullscreen mode

and retried the export.

The corrected export downloaded successfully.

This provided a simple failure-and-recovery check without modifying the DynamoDB source data.

A useful lesson: verify the file at two levels
The most useful lesson from this test was not simply that the export completed successfully.

It was that CSV verification should happen at two different levels.

First, inspect the raw file to determine what the exporter actually produced.

Then open the file in the intended consumer, such as Excel, to determine how that application interprets it.

Those are not always the same thing.

In this test, the raw CSV proved that formula-like strings were neutralized and Unicode text was present correctly. Excel confirmed the formula-safety behavior, but its direct CSV-opening path displayed the Unicode value incorrectly.

Without inspecting the raw file first, it would have been easy to incorrectly attribute that display behavior to the exporter.

Conclusion
Tables provided a straightforward streaming workflow for exporting DynamoDB results to CSV, while also exposing important behaviors before the export was started.

For this controlled eight-item dataset, the export:

  • preserved CSV structure for commas, quotes, and newlines;
  • serialized complex DynamoDB values;
  • preserved numbers, booleans, nulls, and binary data in appropriate CSV representations;
  • neutralized formula-like strings before spreadsheet use;
  • preserved the tested Unicode value in the raw file; and
  • recovered cleanly after an invalid destination filename was rejected.

The Excel test also highlighted an important practical point: a correct CSV file and a correct spreadsheet rendering are two separate things worth verifying.

For DynamoDB exports that may eventually be opened in spreadsheet software, checking both makes the export much easier to trust.

Give it a try on https://tables.serverlesscreed.com/

Top comments (2)

Collapse
 
shieldxbot profile image
shieldx •

Việc xử lý các kiểu dữ liệu phức tạp như Map hoặc List trong DynamoDB khi chuyển sang CSV thực sự là một cơn ác mộng nếu không có chiến lược parse chuẩn ngay từ đầu. Mình từng gặp rắc rối lớn khi các ký tự đặc biệt hoặc dấu phẩy nằm ngay trong giá trị của một attribute khiến cấu trúc file CSV bị lệch hoàn toàn khi load vào Excel hoặc dùng cho các pipeline data khác. Thay vì chỉ export thô, mình thường phải viết thêm một bước transform nhẹ để stringify các object phức tạp hoặc dùng delimiter khác như pipe để tránh xung đột dữ liệu. Nếu dataset của bạn lớn, việc tính toán đến giới hạn của Read Capacity Unit (RCU) cũng cực kỳ quan trọng để tránh làm ảnh hưởng đến performance của ứng dụng đang chạy thực tế.

Collapse
 
palak_jain_427d9b8870a520 profile image
Palak Jain •

Helpful!!