SQL Script
A .sql file is a plain-text database dump — a snapshot of tables, rows, and schema definitions exported by mysqldump, pg_dump, or sqlite3 .dump. Opening it in a text editor shows the raw SQL statements; importing it into the matching database engine recreates the original database.
Conversion not yet available. SQL dump files contain database-specific dialect and schema definitions that require engine-specific parsing.
Common questions
What is a .sql file and how do I open it?
A .sql file is a plain text document containing database statements exported by a database management tool. Open it with any text editor to inspect the contents. You will see table creation commands, data insertion statements, and often comment headers identifying the source database and export date. The file represents a snapshot of database structure and data at the time of export.
How do I import a .sql file into my database?
For MySQL: mysql -u root -p database_name < dump.sql. For PostgreSQL: psql -U postgres -d database_name -f dump.sql. For SQLite: sqlite3 database.db < dump.sql. The target database must exist before import. phpMyAdmin also accepts .sql uploads via its Import tab.
Is it safe to run a .sql file I received?
Exercise extreme caution. A dump file can contain any valid database statement including commands that delete tables, modify permissions, or execute procedures with system access. Never run an untrusted dump directly against a production database. Review contents in a text editor first and import into an isolated test environment to verify safety before applying to any system with real data.
Why does my MySQL dump fail when I import it into PostgreSQL?
MySQL and PostgreSQL use incompatible SQL dialects. mysqldump output contains backtick quoting, AUTO_INCREMENT, ENGINE=InnoDB, and MySQL-specific conditional comments that PostgreSQL rejects as syntax errors. Use pgloader for automated MySQL-to-PostgreSQL migration or mysql2sqlite for SQLite targets. Complex schemas with stored procedures may still need manual review after automated conversion.
How do I tell which database tool created a .sql file?
Check the first 20 lines. mysqldump files begin with -- MySQL dump and the server version. pg_dump files start with -- PostgreSQL database dump. sqlite3 .dump files open with BEGIN TRANSACTION followed directly by CREATE TABLE statements. phpMyAdmin dumps include -- phpMyAdmin SQL Dump in the header.
What is the difference between a .sql dump file and the SQL language?
SQL is a query language defined by ISO 9075 for interacting with relational databases. A .sql dump file is a specific export artifact — a text file containing SQL statements produced by a backup tool. The file uses the language, but the language exists independently of any file.
How do I handle a .sql file that is too large to open in a text editor?
Use command-line tools: wc -l dump.sql counts lines, head -50 dump.sql previews the header, and split -l 100000 dump.sql chunk_ breaks it into smaller files. For import, pipe directly to the database client without opening the file: mysql -u root -p db < dump.sql handles multi-gigabyte files without loading them into memory.
What makes .SQL special
Beneath the extension
Unlike most formats FileDex covers, .sql files have no specification. There is no ISO document defining what a .sql dump file must contain, no magic bytes at offset zero, no mandatory header. The extension is pure convention: a plain-text file holding SQL statements, produced by whatever database tool exported it. The IANA registered application/sql as the official MIME type in April 2013 through RFC 6922, but that RFC describes the SQL language media type, not a dump file structure. Detection is entirely heuristic — the Unix file command identifies .sql by spotting SQL keywords and comment patterns in the first few hundred bytes.
Continue reading — full technical deep dive
How dump files differ by engine
The three most common dump tools produce structurally different output, and recognizing which tool created a file is the first step when handling an unknown .sql dump.
mysqldump (MySQL/MariaDB) opens with a comment block containing the MySQL version, host, and database name. It emits SET statements to configure character encoding, foreign key checks, and SQL mode before any table definitions. Tables appear as DROP TABLE IF EXISTS followed by CREATE TABLE with engine-specific clauses like ENGINE=InnoDB and DEFAULT CHARSET=utf8mb4. Data uses multi-row INSERT INTO with batched VALUES syntax for performance. The entire output is engine-locked to MySQL dialect.
pg_dump (PostgreSQL) begins with a comment header identifying the PostgreSQL version and dump tool version. It uses SET statements for client_encoding, statement_timeout, and lock_timeout. Schema definitions use PostgreSQL syntax — double-quoted identifiers, SERIAL/IDENTITY for auto-increment, and schema-qualified names like public.users. For data, pg_dump defaults to the COPY command (a PostgreSQL-specific bulk loading syntax) rather than INSERT statements, making its output incompatible with MySQL without conversion.
sqlite3 .dump wraps everything in BEGIN TRANSACTION and COMMIT for atomic restore. Schema uses SQLite's permissive type system — CREATE TABLE with type affinities rather than strict SQL types. Data appears as individual INSERT INTO statements. The output is the simplest and most portable of the three, but SQLite's limited ALTER TABLE support means schema migration dumps may not translate to other engines.
Historical roots
Edgar Frank Codd published "A Relational Model of Data for Large Shared Data Banks" in 1970 while at IBM's San Jose Research Laboratory. This paper introduced the mathematical foundation — relational algebra and relational calculus — that replaced the hierarchical and network database models then dominant. Four years later, IBM researchers Donald Chamberlin and Raymond Boyce developed SEQUEL (Structured English Query Language) as the first practical implementation of Codd's relational operators for the System R prototype. A trademark dispute forced the name change to SQL. Oracle shipped the first commercial SQL database in 1979. ANSI standardized the language as SQL-86 (X3.135-1986), followed by ISO adoption as ISO 9075 in 1987. The standard has been revised through SQL-92, SQL:1999, SQL:2003, SQL:2011, SQL:2016, and most recently SQL:2023, which added property graph queries and JSON type enhancements.
File structure patterns
Despite engine differences, dump files share a common skeleton. They open with comment headers identifying the source tool and version. Configuration SET statements follow, adjusting session variables for a clean import. Then come CREATE TABLE statements defining schema — columns, types, constraints, indexes. Finally, INSERT or COPY statements carry the actual data rows. Some dumps include CREATE INDEX, ALTER TABLE for foreign keys, and CREATE TRIGGER or CREATE FUNCTION for stored logic. Transaction wrappers (BEGIN/COMMIT) may or may not be present depending on the tool and flags used.
Encoding defaults to UTF-8 in modern dumps, but older mysqldump files may use latin1 or the database's configured character set. The mysqldump header typically includes SET NAMES utf8mb4 to declare the encoding, while pg_dump sets client_encoding explicitly. SQLite dumps inherit the database's pragma encoding, which defaults to UTF-8.
The portability wall
While ISO 9075 defines a standard SQL language, vendor implementations diverge significantly. A mysqldump file uses backtick quoting, AUTO_INCREMENT, ENGINE=InnoDB, and multi-row INSERT syntax. A pg_dump file uses double-quote quoting, SERIAL/IDENTITY, COPY FROM stdin, and PostgreSQL-specific types like JSONB and TIMESTAMPTZ. Feeding one engine's dump into another produces a cascade of syntax errors.
Conversion tools exist but involve trade-offs. mysql2sqlite strips MySQL-specific syntax and rewrites it for SQLite, but loses stored procedures, triggers, and some data types. pgloader can migrate MySQL to PostgreSQL in a single command, handling type mapping and encoding conversion, but complex schemas with engine-specific features require manual review.
Security: never execute blindly
RFC 6922's security considerations section warns explicitly: SQL is "a full-fledged programming language" and dump files may contain statements that drop tables, escalate privileges, create backdoor accounts, or exfiltrate data via INTO OUTFILE. A malicious .sql file can embed DROP DATABASE, GRANT ALL PRIVILEGES, or CREATE FUNCTION with arbitrary logic inside what appears to be an ordinary database backup.
SQL injection remains in the OWASP Top 10 — ranked A03 in 2021 (94% of applications tested showed some form of injection vulnerability, with 274,000 occurrences) and A05 in 2025. While injection typically targets web applications, the same principle applies to dump files: executing untrusted SQL runs arbitrary commands against your database with whatever privileges the importing user holds.
Before importing any .sql file from an external source, triage it: run wc -l to check line count, head -50 to inspect the header and identify the source tool, and grep for dangerous keywords like DROP, GRANT, INTO OUTFILE, and CREATE FUNCTION. Never import a dump file with a privileged database account when a restricted one will suffice.
The phpMyAdmin factor
Approximately 35% of .sql files in circulation are phpMyAdmin exports. This is the most likely context for a non-developer encountering a .sql file — a WordPress site backup downloaded from a shared hosting control panel. phpMyAdmin's export uses mysqldump-compatible syntax with additional comment markers identifying the phpMyAdmin version. These files can be re-imported through phpMyAdmin's Import tab, the mysql command-line client, or any MySQL-compatible tool. The critical detail for WordPress users: the .sql file contains the entire wp_options table, which stores the site URL — importing a backup to a different domain requires find-and-replace on the serialized PHP data in that table, not just a simple text substitution.
.SQL compared to alternatives
| Formats | Criteria | Winner |
|---|---|---|
| .SQL DUMP vs .CSV | Data fidelity SQL dumps preserve complete schema — column types, constraints, indexes, foreign keys, and multi-table relationships. CSV is flat tabular data with no type information, no relationships, and no schema definition. | SQL DUMP wins |
| .SQL DUMP vs .SQLITE .DB | Portability A SQLite .db file is a self-contained binary database readable by any SQLite library on any platform. A SQL dump is text tied to a specific engine's dialect — mysqldump output fails on PostgreSQL without conversion. | SQLITE .DB wins |
| .MYSQLDUMP vs .PG_DUMP | Cross-engine compatibility mysqldump uses backtick quoting, AUTO_INCREMENT, ENGINE= clauses, and multi-row INSERT VALUES. pg_dump uses double-quote quoting, SERIAL/IDENTITY, COPY FROM stdin, and schema-qualified names. Neither format imports into the other without dialect conversion. | Draw |
Technical reference
- MIME Type
application/sql- Developer
- IBM (Edgar Codd / Donald Chamberlin)
- Year Introduced
- 1974
- Open Standard
- Yes — View specification
Binary Structure
A .sql dump file is plain text with no binary structure or magic bytes. The file opens with a comment header block — lines beginning with -- (double-dash) or enclosed in /* */ — identifying the dump tool, version, host, database name, and timestamp. Following the header, SET statements configure the session: character encoding (SET NAMES utf8mb4), foreign key checks (SET FOREIGN_KEY_CHECKS=0), and SQL mode. The body contains CREATE TABLE statements defining columns, types, constraints, and indexes, followed by INSERT INTO statements carrying the actual data rows. Some dumps include ALTER TABLE for deferred foreign keys and CREATE INDEX for performance indexes. mysqldump may wrap sections in conditional comments (/*!40101 ... */). pg_dump uses COPY ... FROM stdin for bulk data instead of INSERT. sqlite3 .dump wraps the entire output in BEGIN TRANSACTION and COMMIT for atomic restore. Line endings vary (CRLF or LF). Encoding is typically UTF-8 but depends on the source database configuration.
Conversion not yet available. SQL dump files contain database-specific dialect and schema definitions that require engine-specific parsing.
Attack Vectors
- Blind execution of malicious dumps — importing an untrusted .sql file runs all contained statements, which may DROP tables, DELETE data, INSERT backdoor accounts, or GRANT elevated privileges to attacker-controlled users
- Stored procedure injection — a dump can CREATE FUNCTION or CREATE TRIGGER with arbitrary logic that executes on future database operations, persisting the attack beyond the initial import
- Data exfiltration via INTO OUTFILE — MySQL's SELECT INTO OUTFILE writes query results to the server filesystem, allowing an attacker-crafted dump to leak sensitive data to a readable location
- Privilege escalation via GRANT — a dump containing GRANT ALL PRIVILEGES statements can elevate a low-privilege account to full database administrator if imported by a sufficiently privileged user
Mitigation: FileDex displays .sql files as read-only text for format reference only. No SQL execution, no database connection, no server-side processing. Content is rendered in the browser with no statement evaluation.
- Specification RFC 6922 — The application/sql Media Type (IANA Registration)
- Specification ISO/IEC 9075:2023 — Information technology — Database languages SQL
- Documentation mysqldump SQL-Format Output — MySQL 8.4 Reference Manual
- Documentation pg_dump — PostgreSQL Documentation
- History SQL — Wikipedia (language history and ISO standardization)