How to excel to sql insert statements vs pgadmin csv import — which is faster?
- Step 1Decide by data size and purpose — Under a few thousand rows, version-controlled, needs review → generate INSERTs here. Tens of thousands of rows, one-off bulk load, speed-critical → use pgAdmin CSV import or
COPY/LOAD DATA. The code-gen quota (max 10,000 rows even on Pro+Media) is the practical ceiling for the INSERT path. - Step 2For the INSERT path, open the generator — Use the JSON to SQL converter (the Excel → SQL entry redirects there). It accepts
.xlsx,.xls,.ods,.csv,.jsonand reads the first sheet. - Step 3Configure dialect and conflict handling — Pick PostgreSQL / MySQL / SQLite, keep Include CREATE TABLE + IF NOT EXISTS on, and tick ON CONFLICT DO NOTHING for an idempotent seed — something the GUI CSV importers don't offer natively.
- Step 4For the CSV path, prepare the file — If you instead choose CSV import, export the sheet to CSV (or use the whitespace trimmer and empty-row remover to clean it). pgAdmin and Workbench need the target table to already exist with matching columns.
- Step 5Run and verify counts — After generating INSERTs, the stats line shows rows / columns / statements. After a CSV import, check the GUI's reported row count. Either way, run a
SELECT COUNT(*)to confirm. - Step 6Store the artifact appropriately — Commit the
.sqlfile to your repo's migrations/seeds; a CSV import leaves nothing committed, so document the import settings separately if you need reproducibility.
INSERT generation vs CSV import — head to head
An even-handed comparison. Neither is universally better; the right choice depends on data size, reviewability needs, and how often you'll re-run it.
| Dimension | Excel → SQL INSERT (this tool) | pgAdmin / Workbench CSV import |
|---|---|---|
| Best at | Seed/fixture/lookup data, ≤ a few thousand rows | Bulk one-off loads, tens of thousands+ rows |
| Speed at scale | Slower (row-by-row VALUES) | Faster (COPY / LOAD DATA streaming) |
| Reviewability | Plain .sql, diffable in Git | No diff; GUI action only |
| Portability | Runs in any SQL client / CI | Tied to the specific GUI dialog |
| Idempotency | ON CONFLICT DO NOTHING built in | Errors on duplicate keys by default |
| Creates the table | Yes (CREATE TABLE included) | Usually needs an existing table |
| Row ceiling | Code-gen quota: 10K (Pro+Media), unlimited (Developer) | No tool-imposed cap |
Method picker by scenario
Concrete situations mapped to the method that fits. When in doubt, size is the deciding factor.
| Scenario | Recommended method | Why |
|---|---|---|
| 50-row country lookup for a repo seed | INSERT generation | Reviewable, idempotent, commits to Git |
| 120,000-row analytics import, one-off | CSV COPY / import | INSERTs would be slow and exceed the row cap |
| Test fixtures re-run in CI | INSERT + ON CONFLICT | Idempotent across reruns |
| Loading into a brand-new empty table | INSERT (includes CREATE TABLE) | No need to pre-create the table |
| Nightly bulk refresh of a staging table | CSV import / COPY | Speed and volume favour streaming load |
Cookbook
Side-by-side artifacts so you can see what each path actually produces and where each shines.
The INSERT artifact (committable)
What this tool generates for a small lookup table — a single self-contained file that a reviewer can read line by line.
CREATE TABLE IF NOT EXISTS "country" (
"iso" TEXT,
"name" TEXT
);
INSERT INTO "country" ("iso", "name")
VALUES
('GB', 'United Kingdom'),
('FR', 'France') ON CONFLICT DO NOTHING;The equivalent pgAdmin CSV import
The CSV path requires the table to exist, then a COPY. There's no committable artifact and no skip-on-conflict.
-- pre-create the table yourself: CREATE TABLE country (iso text, name text); -- pgAdmin Import/Export runs, under the hood: COPY country (iso, name) FROM '/path/country.csv' WITH (FORMAT csv, HEADER true); -- duplicate iso? COPY errors out.
Where INSERTs win: idempotent CI
Re-running the INSERT file in CI is a no-op on existing rows. The CSV COPY has no equivalent and must be guarded with a truncate or staging table.
Run 1: 2 rows inserted.
Run 2 (same file): 0 rows changed, no error.
(thanks to ON CONFLICT DO NOTHING)
CSV COPY run 2: ERROR duplicate key value
→ needs TRUNCATE or a temp staging table first.Where CSV wins: 120K rows
Above the code-gen row cap, INSERT generation truncates and is slow to execute. A COPY streams the whole file in one pass.
INSERT path: capped at 10,000 rows (Pro+Media),
and 120K INSERT VALUES is slow to run.
CSV path:
COPY events FROM 'events.csv' WITH (FORMAT csv, HEADER true);
-- loads all 120,000 rows in seconds, no cap.Hybrid: generate the schema, load with CSV
Use this tool to generate just the CREATE TABLE (with inferred types) from a sample, then bulk-load the full data via CSV import.
1. Generate from a 50-row sample, CREATE TABLE only:
CREATE TABLE IF NOT EXISTS "events" (
"id" INTEGER, "label" TEXT, "amount" DOUBLE PRECISION
);
2. Then COPY the full 120K-row CSV into it.Edge cases and what actually happens
INSERT path on 120,000 rows
Exceeds capThe code-generation quota tops out at 10,000 rows (Pro+Media) — Developer is unlimited but execution is still slow row-by-row. For six-figure row counts, a CSV COPY/LOAD DATA is the right tool; use this generator only for the CREATE TABLE.
CSV import needs the table to exist first
Pre-step requiredpgAdmin and Workbench import into an existing table with matching columns. The INSERT path includes CREATE TABLE, so it doesn't need that pre-step — a genuine advantage for greenfield tables.
Duplicate keys during CSV COPY
Import errorCOPY/LOAD DATA errors on duplicate primary keys with no built-in skip. The INSERT path's ON CONFLICT DO NOTHING handles this natively. To dedupe a CSV first, use the CSV deduplicator.
Excel dates either way
By designBoth paths struggle with Excel serial dates: the INSERT path infers INTEGER; a CSV export may emit 45292 too. Standardise the column to ISO text with the date standardizer before doing either.
Encoding/delimiter friction on CSV import
Import configCSV import wizards make you specify encoding, delimiter, quote char, and null string. The INSERT path sidesteps all of that — the SQL is unambiguous. If you do go CSV, the whitespace trimmer reduces surprises.
Multi-sheet workbook for the INSERT path
First sheet onlyThe generator reads only the first sheet. A CSV export also flattens one sheet at a time. Either way, handle one tab per run, or join sheets first.
Auditability requirement
INSERT preferredIf a reviewer must see exactly which rows are loaded (compliance, regulated data), the INSERT .sql file is reviewable in a PR; a GUI CSV import is not. This often outweighs raw speed for seed data.
Float precision on money
Precision risk (both)Decimals infer DOUBLE PRECISION in the INSERT path; a CSV COPY into a float column has the same issue. Define the target column as NUMERIC(p,s) regardless of method for currency data.
Free tier 1 run/day
Quota limitOn Free, code generation is limited to 1 run/day and 100 rows — fine for trying it out, restrictive for real work. CSV import has no such daily cap but offers no reviewable artifact.
Frequently asked questions
Which is faster, INSERTs or CSV import?
CSV import (COPY/LOAD DATA) is faster at scale because it streams rows in one pass; multi-row INSERTs are slower per row. For small seed data the difference is negligible and INSERTs win on reviewability and idempotency.
When should I generate INSERTs instead of importing a CSV?
When the data is small (lookup tables, fixtures, demo data up to a few thousand rows), needs to be reviewed in a pull request, must run in any client/CI, or needs to be idempotent. INSERTs also carry their own CREATE TABLE.
When is CSV import the better choice?
For large one-off bulk loads (tens of thousands of rows and up) where speed matters more than a committable artifact, and where you're fine pre-creating the table and handling duplicates manually.
Does the INSERT generator have a row limit?
Yes — the code-generation quota caps output at 100 rows (Free), 1,000 (Pro), 10,000 (Pro+Media), unlimited (Developer). A CSV COPY has no tool-imposed cap, which is why it's preferred for very large loads.
Can I get idempotent CSV import like ON CONFLICT?
Not natively — pgAdmin/Workbench import errors on duplicate keys. You'd load into a staging table and INSERT ... ON CONFLICT from there. The INSERT path bakes ON CONFLICT in directly.
Do both methods handle Excel dates badly?
Yes. Excel stores dates as serial numbers; the INSERT path infers INTEGER, and a CSV export can carry the serial too. Standardise to ISO text with the date standardizer before either method.
Does the CSV import need the table to exist?
Usually yes — pgAdmin and MySQL Workbench import into an existing table with matching columns. The INSERT generator includes a CREATE TABLE, so it can target a brand-new table.
Can I combine both methods?
Yes — a useful hybrid is to generate just the CREATE TABLE from a small sample here (to get inferred types), then bulk-load the full dataset with a CSV COPY. Best of both: typed schema plus fast load.
Which is more secure for sensitive data?
Generation here runs entirely in your browser via SheetJS — nothing is uploaded. A CSV import means a CSV file exists on disk that you should delete afterward. For sensitive seed data, the in-browser INSERT path leaves a smaller footprint.
Will the same INSERT file work in MySQL Workbench?
If you generated with the MySQL dialect (backtick identifiers, 1/0 booleans, INSERT IGNORE), yes — paste it into Workbench's query editor. A Postgres-dialect file won't run unchanged in MySQL.
What about very wide tables (many columns)?
Both methods handle wide tables; the INSERT path quotes every identifier so reserved-word columns are safe. Very wide rows make the INSERT text large, but that's cosmetic — execution still works within the row cap.
Is there an underlying engine I can reuse for JSON?
Yes — this is the same engine as the JSON to SQL converter. If your source is JSON rather than Excel, point it there directly; the options and output are identical.
Privacy first
Every JAD Excel tool runs entirely in your browser using SheetJS and ExcelJS. Your spreadsheets, formulas, and data never leave your device — verified by zero outbound network requests during processing.