Generate seed data without hand-typing rows
The Mock SQL Rows Generator turns a quick table definition into a block of ready-to-run INSERT statements filled with realistic fake data. Instead of writing seed rows by hand, you declare each column and its type, pick a SQL dialect, and copy out as many rows as you need to populate a development or staging database.
How it works
You build a lightweight schema in the browser: a table name plus a list of columns, each with a chosen type. For every requested row the tool walks your columns and emits an appropriate value — an incrementing integer for an auto id, an RFC 4122 version-4 string for a uuid, a name drawn from a curated pool for full name, and so on. String values are wrapped in single quotes with any internal quote doubled (O'Brien becomes 'O''Brien'), which is the SQL-standard way to escape literals and keeps the output safe to run.
Identifier quoting follows the dialect you select: MySQL uses backticks around table and column names, while PostgreSQL and SQLite use double quotes. You can emit one compact multi-row INSERT or a separate statement per row. A seeded random source keeps results reproducible until you press Reshuffle.
Tips and notes
- Put your primary key first as an
auto idcolumn so the rows number cleanly from 1. - Use the
datetimetype forcreated_atandupdated_atcolumns — values come out inYYYY-MM-DD HH:MM:SSform that all three dialects accept. - For large seeds, the single multi-row mode is faster to execute than hundreds of individual statements.
- Everything runs locally, so you can safely paste real internal table and column names without leaking anything.
Dialect differences that matter
The three supported dialects are mostly compatible for INSERT statements, but identifier quoting differs and some column type conventions vary:
| Feature | PostgreSQL | MySQL | SQLite |
|---|---|---|---|
| Identifier quoting | "column_name" | `column_name` | "column_name" |
| Boolean literal | TRUE / FALSE | 1 / 0 | 1 / 0 |
| UUID type | uuid (native) | CHAR(36) | TEXT |
| Auto-increment | SERIAL or GENERATED | AUTO_INCREMENT | INTEGER PRIMARY KEY |
The generator applies the right quoting for whichever dialect you choose. If you later switch databases, re-generate with the new dialect selected rather than search-and-replacing backticks.
Example output (PostgreSQL, 3 rows)
For a table named users with columns id (auto id), full_name (full name), email (email), created_at (datetime), the output looks roughly like:
INSERT INTO "users" ("id", "full_name", "email", "created_at") VALUES
(1, 'Alice Thornton', '[email protected]', '2024-03-12 08:44:21'),
(2, 'Marcus Webb', '[email protected]', '2024-03-14 15:07:55'),
(3, 'Priya Nair', '[email protected]', '2024-03-15 10:31:09');This pastes directly into psql, DBeaver, or a seed migration file. Because the names and emails are varied rather than sequential (user1, user2), queries that filter, group, or sort by name behave as they would with real data.
When to use multi-row vs. one-per-row INSERT
A single multi-row INSERT (all rows in one statement) executes faster because the database parses one statement and performs one transaction commit. This matters for seeding thousands of rows. Use one-per-row when you want to comment out specific rows, insert them conditionally, or run them through an ORM that expects single-record inserts.