SQL File Documentation

Summary

A .sql file is a Structured Query Language Data File: a plain-text file of SQL statements, not a database. It usually holds either a database dump (CREATE TABLE plus many INSERT statements that rebuild a database) or a script of queries and schema changes. You read it in any text editor, but to use it you execute it against a database server — for example mysql dbname < file.sql, or run it in DBeaver or pgAdmin. Its MIME type is application/sql.

Technical details

FeatureValue
Full nameStructured Query Language Data File (SQL script / database dump)
File extension.sql
MIME typeapplication/sql
Format typePlain-text source file of SQL statements
Is it a database?No — it is the text instructions that build or change one
Character encodingUTF-8 or ASCII (varies by dump tool and database)
CompressionNone (plain text); often gzip-compressed as .sql.gz for storage
Magic numberNone; often starts with a comment (-- or /* */) or a keyword
Language standardSQL: ANSI X3.135‑1986, ISO/IEC 9075 (1987, revised regularly)
Open standardYes (SQL is an ANSI/ISO standard)
Statement typesDDL (CREATE/ALTER/DROP), DML (INSERT/UPDATE/DELETE), queries, routines
Produced bymysqldump, pg_dump, phpMyAdmin, and every RDBMS export
Executed byMySQL/MariaDB, PostgreSQL, SQL Server, Oracle, SQLite, etc.
Read/edit withAny text editor (Notepad++, VS Code); run in DBeaver, MySQL Workbench, psql/mysql CLI
Dialect portabilityLimited — a MySQL dump may not import unchanged into PostgreSQL or SQLite
Related extensions.db, .sqlite, .csv, .dump, .bak, .mdb
SpecificationISO/IEC 9075 (SQL)
Syntax at a glance

A .sql file is plain UTF-8/ASCII text with no binary signature, so it is detected by content, not bytes. Line comments start with -- and block comments with /* … */; statements are separated by a semicolon (;). Dumps usually open with a header comment naming the tool, for example -- MySQL dump 10.x or -- PostgreSQL database dump, then run CREATE TABLE definitions (DDL) followed by long runs of INSERT INTO … VALUES rows (DML). Because it is only text, it opens instantly in any editor — but the statements do nothing until they are executed against a database engine. It is not itself a database.

What is a SQL file?

A .sql file is a plain-text file containing statements written in Structured Query Language, the standard language for defining and querying relational databases. SQL was standardised by ANSI in 1986 (X3.135) and by ISO in 1987 (ISO/IEC 9075), and it has been revised roughly every few years since. The .sql extension is a convention, not part of the standard: essentially every database engine — MySQL and MariaDB, PostgreSQL, Microsoft SQL Server, Oracle, SQLite — reads and writes files with this extension.

The key point, and the source of most confusion, is that a .sql file is not a database. It is source code: a list of instructions that build, change or query a database when executed. You do not open a .sql to “see the data” the way you open a spreadsheet; you run it against a database server, and the statements take effect in that database. The data store itself is a different file (a .db/.sqlite file, or a server’s internal storage such as an .mdf). A .sql file is the recipe, not the meal.

The two kinds of SQL file: dumps and scripts

Almost every .sql file you meet is one of two things.

A database dump (or backup) is produced by an export tool such as mysqldump, pg_dump, or phpMyAdmin’s Export. It contains the CREATE TABLE statements that define the schema, followed by many INSERT statements carrying the data, so running the whole file against an empty database recreates the original. This is the typical .sql you download when backing up a WordPress site or moving a web app’s database to a new server.

A script is a hand-written or generated sequence of statements: queries, a schema migration, stored-procedure or trigger definitions, or a set of updates a developer or DBA runs in order. A migration script, for example, might ALTER a table and back-fill a column. Both kinds are just text; the difference is purely in what the statements do.

DDL and DML: the two statement families

The statements inside a .sql file fall into two broad families, and a dump normally contains both.

FamilyStatementsPurpose
DDL (Data Definition Language)CREATE, ALTER, DROPDefine or change the structure: tables, indexes, views, constraints
DML (Data Manipulation Language)INSERT, UPDATE, DELETEAdd, change or remove the actual rows of data

A dump leads with DDL to build empty tables, then runs DML — usually long runs of INSERT — to fill them. Scripts may also contain queries (SELECT), routine definitions (stored procedures, triggers, functions) and transaction-control statements. A minimal example combining DDL and DML:

CREATE TABLE customers (
  id     INT PRIMARY KEY,
  name   VARCHAR(255) NOT NULL,
  joined DATE
);

INSERT INTO customers (id, name, joined) VALUES
  (1, 'Ada Lovelace', '2025-01-14'),
  (2, 'Alan Turing',  '2025-03-02');

This first defines a table, then inserts two rows. A real dump repeats that pattern across every table in the database, often for thousands or millions of rows.

Anatomy of a real dump file

A dump is not just raw statements; the tool wraps them in structure. It usually opens with header comments naming the tool and version, such as -- MySQL dump 10.x or -- PostgreSQL database dump, along with the server version and the dump date — the quickest way to tell which engine a file came from. Comments use -- for a single line or /* … */ for a block; MySQL also uses executable comments of the form /*!40101 … */ that run only on versions at or above the number given.

The body typically brackets the data with session settings: it may disable foreign-key checks and unique checks before the inserts and re-enable them afterward, so the rows load fast and in any order without tripping constraints. Large dumps batch many rows into a single multi-row INSERT to cut per-statement overhead, and they may wrap the load in a transaction so a failure rolls back cleanly. Statements are separated by a semicolon (;); understanding that separator matters when a client asks how to run the file, because some tools split on it.

Executing a SQL file

Because the file is only text, running it means feeding it to a database engine. From a terminal, the classic forms are mysql -u user -p dbname < file.sql for MySQL/MariaDB and psql dbname -f file.sql for PostgreSQL; each reads the file and executes every statement in order against the named database. For SQLite the equivalent is sqlite3 new.db < file.sql, which runs the script against a new .db file. Graphical tools do the same thing: DBeaver, MySQL Workbench, pgAdmin and phpMyAdmin all have an Import or Execute-Script action that opens a connection and runs the file.

Reading a .sql and running it are different operations. Any text editor (Notepad++, VS Code) opens it instantly for inspection and syntax highlighting, but an editor does not execute anything. Nothing in the file changes a database until a client with a live connection runs the statements. This is also why a .sql cannot be “converted” to CSV or Excel by a file converter: the row data only becomes a table once the dump is executed into a database, from which you then export the tables.

Dialect differences and why imports fail

SQL is a standard, but every engine extends it, and dumps are written for the engine that produced them. A MySQL dump is full of MySQL-specific syntax that other engines reject: back-tick quoted identifiers (`table`), AUTO_INCREMENT columns, storage-engine clauses like ENGINE=InnoDB, and its /*!…*/ conditional comments. PostgreSQL instead uses SERIAL or identity columns and double-quoted identifiers; SQL Server uses IDENTITY and square brackets; SQLite is far more permissive but lacks many types.

The practical result is the most common support question about .sql files: an import fails with syntax errors because a dump made for one engine is being loaded into another. The fix is to import the dump into the same engine it came from, or to adapt the script — strip the engine clauses, translate the auto-increment syntax, and quote identifiers the target’s way. There is no universal, lossless converter between dialects for arbitrary dumps.

Executing untrusted SQL: the real risk

A .sql file is plain text and completely safe to read; there is no code that runs merely by opening it in an editor. The danger is entirely in executing it, and it is real. A script can contain destructive statements — a stray DROP TABLE, an unfiltered DELETE or a broad UPDATE — that silently wipe or corrupt data when run. An untrusted dump can also carry deliberately harmful payloads: statements that create a privileged user, alter permissions, or (in engines and configurations that allow it) invoke functions that touch the file system or run shell commands. Running such a file against a live database with a privileged account can do exactly what those statements say.

The defensive habits are straightforward. Inspect a .sql in a text editor before executing it, watching for DROP, DELETE, GRANT and user-creation statements you did not expect. Run an unfamiliar dump against a throwaway or test database first, using an account with only the privileges it needs, and keep a backup of any database you import into. Remember too that dumps often contain sensitive data — password hashes, personal records — so a .sql backup should be treated as confidential and stored accordingly.

FAQ

Is a SQL file a database?

No. A .sql file is the text instructions (schema, data and queries) to build or change a database. The database itself is a separate file such as .db/.sqlite, or it lives inside a server. Running the .sql is what creates or populates that database.

How do I get CSV or Excel out of a .sql dump?

Import the dump into a database first, then export the resulting tables to CSV or Excel from a tool like DBeaver, MySQL Workbench or phpMyAdmin. There is no direct file-to-file converter, because a dump is schema and statements, not a flat table of rows.

References