Dev
Dummy Database Seed Generator
Writing SQL INSERT statements by hand for every test environment reset is slow. Column order, quoting rules, and boolean syntax all differ between MySQL, PostgreSQL, and SQLite. A dummy database seed generator handles that automatically: select a table schema, pick your dialect, set a row count, and get ready-to-run INSERTs. Four schemas are available. Users generates id, name, email, role, and created_at. Products generates id, name, category, price, and in_stock with correct boolean literals per dialect. Orders generates a UUID-based id, user_id, total, status, and created_at. Sessions generates id, user_id, token, and expires_at with dialect-correct timestamp arithmetic — PostgreSQL uses NOW() + INTERVAL '24 hours', SQLite uses DATETIME('now', '+1 day'). Wrap pasted statements in BEGIN; ... COMMIT; to speed up bulk inserts and enable rollback.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Select the table schema you want to populate from the Table dropdown: users, products, orders, or sessions.
- Choose your SQL dialect — PostgreSQL, MySQL, or SQLite — to match your target database engine.
- Set the row count to however many INSERT records you need for your test or seed scenario.
- Click Generate to produce ready-to-run SQL statements with realistic fake field values.
- Copy the output and paste it into your database client console, seed file, or migration script.
Use Cases
- •Seeding a local PostgreSQL database with 50 users before a code review demo
- •Generating orders rows with varied timestamps to debug a Knex date-range query
- •Populating a SQLite database for a React Native prototype without a live backend
- •Creating realistic product records to test Stripe price formatting in a staging environment
- •Adding sessions rows to load-test a background cleanup job in a Docker dev container
Tips
- →Generate a users table first, then generate orders using the same row count — user_id references will align numerically for simple join testing.
- →For PostgreSQL, the output uses SERIAL-compatible id values; if your table uses UUID primary keys, swap the id column type before running the script.
- →Wrap pasted INSERT statements in BEGIN; ... COMMIT; to speed up bulk inserts and make rollback easy if something goes wrong.
- →When testing pagination or sorting, generate at least 50 rows so edge cases at page boundaries and sort-order ties actually appear in query results.
- →If your ORM uses underscored column names (created_at, is_active), the generated schema already matches — no column renaming needed for Rails, Django, or Laravel defaults.
- →For CI pipelines, generate a fixed seed file once and commit it to your repo rather than regenerating each run, ensuring consistent test data across all environments.
FAQ
how do I generate SQL INSERT statements with fake data for testing
Select a table schema (users, products, orders, or sessions), pick your SQL dialect, and set the row count. The generator outputs ready-to-run INSERT statements you can paste directly into a database client, a .sql seed file, or a Knex/Flyway migration script.
does the generated SQL work with PostgreSQL, MySQL, and SQLite
Yes — each dialect gets its own correct syntax. PostgreSQL uses TRUE/FALSE booleans and NOW() for timestamps. MySQL uses 1/0 for booleans and CURRENT_TIMESTAMP. SQLite uses DATETIME('now', '+1 day') for expiry calculations. Switching the dialect dropdown regenerates all statements instantly.
is it safe to run this fake SQL data in a production database
No. The output is entirely fictional and meant only for development, staging, and CI environments. Running it in production risks triggering email notifications on fake addresses, corrupting real records, and creating compliance issues if your schema holds regulated data.
does the generator handle UUID primary keys for the orders table
Yes — the orders schema uses a UUID-formatted id, matching the pattern that PostgreSQL's gen_random_uuid() or your application's UUID library would produce. The other three schemas (users, products, sessions) use sequential integer ids starting at 1. If your users table uses UUIDs, adapt the id column accordingly before running.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.