Using SeedQL
Getting started
Create your first project and generate realistic data, from the app. No code required.
SeedQL fills a database with realistic, referentially-consistent test data. You point it at a schema, choose how many rows you want per table, and it works out the rest.
There are two ways in. Pick whichever matches what you have.
Option A: connect your own database
Best when you already have a schema and want data that fits it exactly.
Projects → New project → Connect your database.
You will be asked for:
- Project name, anything; it is just a label
- Database type, PostgreSQL, MySQL or SQLite
- Connection string, for example
postgresql://user:pass@host:5432/mydb - SSL mode, leave as
requireunless your database says otherwise - Schema name,
publicunless you use a different one
SeedQL tests the connection before saving. If it fails, the error tells you what the database actually said rather than a generic message, so a wrong password reads differently from a firewall block.
Once connected, SeedQL reads your schema: tables, columns, types, nullability and the foreign keys between them. Nothing is written at this stage.
Option B: start from a template
Best when you want to try SeedQL, or you need a realistic schema and do not have one yet.
Projects → New project → Choose a template. Three ship:
| Template | What it contains |
|---|---|
| E-commerce | Customers, products, orders, line items, shipments |
| SaaS | Accounts, users, subscriptions, invoices, usage |
| Blog | Authors, posts, comments, tags |
Each is a complete relational schema with real foreign keys, so you can see referential integrity working before pointing SeedQL at anything of your own.
Generating your first rows
Open the project and click Generate.
You will see Table configuration: every table in your schema with a row count next to it. Set the numbers you want, untick anything you want to skip, and click Generate.
Order does not matter. SeedQL reads the foreign keys and fills parents before children, so an orders row always references a customers row that exists.
When it finishes you get:
- Total rows and a per-table breakdown
- Elapsed time
- A seed value
The seed is the important part
The seed is a number that determines the data. The same seed with the same table configuration produces the same rows, every time.
That matters when a test fails. Note the seed and you can recreate the exact dataset the failure happened on, instead of hoping it reproduces. Without one, a data-related bug is a rumour.
Getting the data out
Two choices after generating:
Download your data exports the rows as SQL, CSV or JSON.
Push rows writes them straight into the connected database. This is the one most people want, and it is covered next.
Next
- Pushing data into a database
- Snapshots, capture a schema so you can restore it later
- Team and roles, who can do what