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 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.

Comments

Comments are welcome — please read the comment policy first. Powered by giscus and GitHub Discussions.