How I generate SQL INSERT statements from CSV or JSON
· 3 min read
Sometimes I have a small table of data and need to insert it into a database. For a few rows, writing SQL by hand is fine. For many rows, it is boring and error-prone.
The SQL Insert Generator turns CSV or JSON rows into
INSERT statements.
The simple idea
Input data:
name,email
Ana,ana@example.com
Budi,budi@example.com
SQL output:
INSERT INTO users (name, email) VALUES
('Ana', 'ana@example.com'),
('Budi', 'budi@example.com');
The tool helps with quoting and formatting, but I still review the SQL before running it.
Step 1: know the table name
Decide which table will receive the data.
Example:
users
The table should already exist unless your workflow also creates it separately.
Step 2: check the columns
Column names should match the database table.
CSV headers like this:
name,email
become SQL columns:
(name, email)
If the database column is email_address but the CSV header is email, the insert
may fail unless you rename it.
Step 3: choose the SQL dialect
Different databases quote identifiers and values slightly differently.
Common targets:
- PostgreSQL;
- MySQL;
- SQLite;
- SQL Server.
Choose the dialect that matches your database. This helps avoid small syntax issues.
Step 4: paste CSV or JSON
For CSV, make sure the first row is the header:
name,email,active
Ana,ana@example.com,true
For JSON, an array of objects is easiest:
[
{ "name": "Ana", "email": "ana@example.com", "active": true }
]
The keys become columns.
Step 5: check values and quoting
SQL strings need quotes. Numbers usually do not. Null values should become NULL,
not the string 'NULL', unless you really mean text.
Check examples carefully:
'Ana'
123
NULL
true
The generated SQL should match the column types in your table.
Step 6: review before running
Before running generated SQL, check:
- table name;
- column names;
- row count;
- quote escaping;
- null values;
- date formats;
- boolean values;
- database dialect.
Do not paste generated SQL into production without review.
Step 7: test with a small batch
If the data is important, test with a few rows first.
BEGIN;
-- run a small insert
ROLLBACK;
or use a staging database. Once the shape is correct, run the full insert.
Step 8: think about duplicates
Plain INSERT may fail if rows already exist and a unique constraint is hit.
Depending on the database, you may need patterns like:
ON CONFLICTin PostgreSQL;INSERT IGNOREorON DUPLICATE KEY UPDATEin MySQL;INSERT OR IGNOREin SQLite.
The right choice depends on whether duplicates should be skipped, updated, or treated as an error.
My SQL insert checklist
Before running generated inserts, I check:
- Is the table name correct?
- Do columns match the database?
- Is the SQL dialect correct?
- Are strings escaped correctly?
- Are numbers, booleans, dates, and nulls represented correctly?
- Does the row count match the input?
- Have I tested on staging or inside a transaction?
- What should happen if a row already exists?
Generated SQL saves time, but the database will still do exactly what the SQL says. Review before running it.
Comments
Comments are welcome — please read the comment policy first. Powered by giscus and GitHub Discussions.