SQL converter
Convert SQL table dumps while handling dialects, INSERT rows, schemas, encodings, comments, and spreadsheet targets.
.sql
Format
About SQL
SQL files are text scripts for relational databases, but a .sql extension can mean many different things. It may contain a simple CREATE TABLE followed by INSERT rows, a full application migration, a vendor-specific dump, stored procedures, triggers, indexes, permissions, or seed data. Our tabular converter intentionally targets simple table-shaped SQL data, especially INSERT lists that can be mapped to rows. It can convert SQL to CSV, TSV, JSON, JSONL, YAML, XML, XLSX, ODS, Parquet, HTML, Markdown, or TXT, and it can generate SQL from table-like sources such as CSV, XLSX, JSONL, and Parquet.
There is no single SQL file version. PostgreSQL, MySQL, SQLite, SQL Server, Oracle, and DuckDB use different quoting, types, date literals, copy commands, identity syntax, comments, and dump metadata. A dump may include DELIMITER blocks, backslash commands, bytea strings, escaped newlines, multi-row INSERT statements, or COPY FROM STDIN payloads. A converter that is safe for tabular extracts should not pretend to execute arbitrary scripts. It should parse supported row statements, preserve string quoting carefully, and leave schema behavior such as constraints and triggers for a database engine or migration tool.
Readers and writers include database clients, backup jobs, ORMs, analytics notebooks, application installers, and support teams exporting customer tables. Developers often want CSV or XLSX so non-database reviewers can inspect rows. Analysts may want Parquet for a small extract that later joins with warehouse data. Conversely, a CSV sent by a vendor may need SQL inserts for a test database. The decision is about data movement, not database administration. If the script changes schema or permissions, conversion is the wrong tool and a database restore in an isolated environment is safer.
SQL conversion breaks around dialect and intent. SQL to CSV works when the input is a clear table dump; it cannot preserve indexes, foreign keys, stored procedures, comments, or transaction boundaries. SQL to JSONL maps rows to objects if column names are known. SQL to XLSX is good for review but not for round-tripping a database. CSV to SQL creates generic statements, but you still need to review target database types, escaping, table names, and load performance. Before converting, identify the dialect, search for non-INSERT statements, count parsed rows, and never run unknown SQL just to see what it contains.
Common SQL problems
A SQL dump contains more than table data.
Use /convert/sql-to-csv only on supported INSERT data; restore complex dumps in a disposable database instead.
Reviewers need rows in Excel.
Use /convert/sql-to-xlsx, then compare row counts and spot-check escaped quotes and null values.
A pipeline expects one JSON object per row.
Use /convert/sql-to-jsonl when the SQL source has clear column names and row-oriented INSERT statements.
CSV needs to be loaded into a test database.
Use /convert/csv-to-sql, then adjust table names, column types, and bulk-load strategy for the target engine.
A dump is headed for analytics storage.
Use /convert/sql-to-parquet for table-shaped exports after validating dates, decimals, and nullable columns.