# How I generate SQL INSERT statements from CSV or JSON

A beginner-friendly guide to turning rows of CSV or JSON into SQL INSERT statements, choosing a dialect, checking columns, and avoiding unsafe imports.

- Date: 2026-09-27
- URL: https://ilham.dev/posts/how-to-generate-sql-inserts-from-csv-or-json/
- Markdown: https://ilham.dev/posts/how-to-generate-sql-inserts-from-csv-or-json/index.md
- Tags: sql, csv, json, tools
- Reading time: 3 min


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](/tools/sql-insert-generator/) turns CSV or JSON rows into
`INSERT` statements.

## The simple idea

Input data:

```csv
name,email
Ana,ana@example.com
Budi,budi@example.com
```

SQL output:

```sql
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:

```text
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:

```csv
name,email
```

become SQL columns:

```sql
(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:

```csv
name,email,active
Ana,ana@example.com,true
```

For JSON, an array of objects is easiest:

```json
[
  { "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:

```sql
'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.

```sql
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 CONFLICT` in PostgreSQL;
- `INSERT IGNORE` or `ON DUPLICATE KEY UPDATE` in MySQL;
- `INSERT OR IGNORE` in 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:

1. Is the table name correct?
2. Do columns match the database?
3. Is the SQL dialect correct?
4. Are strings escaped correctly?
5. Are numbers, booleans, dates, and nulls represented correctly?
6. Does the row count match the input?
7. Have I tested on staging or inside a transaction?
8. 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.