Download free sample SQL files instantly — MySQL, PostgreSQL, SQLite, and SQL Server dialects with realistic schemas, INSERT data, indexes, constraints, and migration scripts. All generated in your browser.
Dialect-specific syntax — correct quoting, data types, and auto-increment for each database engine
Schema-only, data-only, full dumps, migrations, and stored procedures
High row-count INSERT files — for benchmarking import performance and testing batch ingestion
Configure dialect, dataset, row count, and every structural option
| Feature | MySQL | PostgreSQL | SQLite | SQL Server |
|---|---|---|---|---|
| Auto-increment | AUTO_INCREMENT | SERIAL / GENERATED | AUTOINCREMENT | IDENTITY(1,1) |
| String quoting | Single quotes + backtick names | Single quotes + double-quote names | Single quotes | Single quotes + [bracket] names |
| Boolean type | TINYINT(1) | BOOLEAN | INTEGER (0/1) | BIT |
| Current timestamp | NOW() | NOW() / CURRENT_TIMESTAMP | datetime('now') | GETDATE() |
| Limit rows | LIMIT n | LIMIT n | LIMIT n | TOP n / FETCH FIRST |
| Backtick names | ✓ Yes | ✗ No | ✗ No | ✗ No |
| Multi-row INSERT | ✓ Yes | ✓ Yes | ✓ Yes (3.7.11+) | ✓ Yes (2008+) |
| IF NOT EXISTS | ✓ Yes | ✓ Yes | ✓ Yes | ✗ Use OBJECT_ID check |
What are sample SQL files used for?
Sample SQL files are used any time you need a realistic database script without writing one by hand. Common use cases include testing database import and migration tools, seeding a development or staging database with realistic-looking data, validating that a backup restore pipeline works correctly, benchmarking INSERT performance, testing SQL parsers and query analysis tools, and providing example fixtures in documentation or tutorials.
The dialect-specific files are particularly useful when building tools that need to handle multiple database engines — MySQL and PostgreSQL look superficially similar but have enough syntax differences (identifier quoting, auto-increment syntax, boolean types) that a parser tested only against one will fail on the other.
What is the difference between MySQL and PostgreSQL SQL syntax?
The most visible differences are identifier quoting, auto-increment syntax, and a few data types. MySQL uses backtick characters (`column_name`) to quote identifiers; PostgreSQL uses double quotes ("column_name"). MySQL uses AUTO_INCREMENT as a column attribute; PostgreSQL uses the SERIAL shorthand or the more modern GENERATED ALWAYS AS IDENTITY. MySQL stores booleans as TINYINT(1); PostgreSQL has a native BOOLEAN type. PostgreSQL also supports RETURNING clauses on INSERT/UPDATE/DELETE, array types, and JSON operators that have no MySQL equivalent.
Why wrap INSERT statements in a transaction?
Wrapping a batch of INSERTs in BEGIN / COMMIT (or START TRANSACTION / COMMIT in MySQL) has two benefits. First, performance: each INSERT without a transaction is its own implicit transaction, which means a disk flush per row. Grouping thousands of rows into one transaction dramatically reduces import time — often by 10–100x on large datasets. Second, atomicity: if the import fails partway through, the entire batch rolls back rather than leaving the table half-populated. For production data loads, transactional imports are almost always the right choice.
What is a multi-row INSERT and why does it matter?
A multi-row INSERT combines multiple rows into a single statement: INSERT INTO users (name, email) VALUES ('Alice', 'alice@example.com'), ('Bob', 'bob@example.com'), .... This is significantly faster than issuing one INSERT per row because it reduces round-trips to the database and parser overhead. All four dialects supported here use this format for the bulk data files. SQLite supports multi-row INSERT since version 3.7.11 (2012); SQL Server supports it since 2008. If you need to support a very old SQLite version, single-row inserts are the safe fallback.
What is the correct way to import a .sql file into MySQL?
From the command line: mysql -u username -p database_name < sample.sql. This pipes the file into the MySQL client. If the dump includes a CREATE DATABASE and USE statement you can omit the database_name argument. From inside the MySQL CLI: SOURCE /path/to/sample.sql;. In phpMyAdmin, use the Import tab and select your file. For PostgreSQL the equivalent is psql -U username -d database_name -f sample.sql. For SQLite: sqlite3 mydb.db < sample.sql.
What is the SQL Server (T-SQL) syntax difference to watch for?
T-SQL uses [square brackets] to quote identifiers (though double quotes also work with SET QUOTED_IDENTIFIER ON). Auto-increment columns use IDENTITY(1,1) instead of AUTO_INCREMENT or SERIAL. Booleans are stored as BIT (0 or 1). There is no LIMIT n — instead use TOP n in the SELECT or FETCH FIRST n ROWS ONLY with ORDER BY. The IF NOT EXISTS check on CREATE TABLE doesn't exist — instead you check IF NOT EXISTS (SELECT 1 FROM sys.objects WHERE object_id = OBJECT_ID(N'TableName')). The T-SQL samples here handle all of these correctly.
What is a foreign key constraint and should I include it?
A foreign key constraint enforces referential integrity between two tables — for example, ensuring that every orders.user_id value actually exists in the users.id column. When loading sample data, foreign keys must be satisfied in insertion order: parent table rows must exist before child table rows that reference them. The generated files handle this by inserting parent tables first. If you're using the SQL as a fixture for testing and don't need integrity enforcement, turning off the foreign key option generates cleaner files that import in any order. In MySQL you can also disable constraint checking temporarily with SET FOREIGN_KEY_CHECKS = 0;.
Can I use these files with an ORM like Prisma, Sequelize, or SQLAlchemy?
Yes, with one caveat. ORMs typically manage schema through their own migration system rather than raw DDL, so the CREATE TABLE statements in these files are best used as a reference or for direct database seeding rather than running through the ORM's migration runner. The most practical approach is to run the schema SQL directly against your database (which the ORM connects to), then use the INSERT data to populate it. Alternatively, take just the INSERT statements from a data-only file and run them after your ORM has created the schema through its own migrations.