Pushing data into a database

Generating gives you rows. Pushing writes them into the database you connected.

From a project, click Generate, set your table configuration, then Push rows.

What happens

SeedQL inserts in dependency order, parents before children, so foreign keys resolve as it goes. Nothing is written until generation succeeds, so a failure part-way through generation leaves your database untouched.

Reading the result

After a push you get a summary. Two numbers matter more than the others.

Rows pushed vs rows requested. If these differ, some rows did not land. The usual cause is a unique constraint your generated data collided with, and the reasons are listed.

Pushed to database. This is a yes/no, and it is derived from tables that actually received rows. If every row failed a constraint, this says no.

That second one exists because an earlier version of SeedQL reported success unconditionally, even when nothing was written. If you are automating against the API, read this field rather than trusting the status code. The API errors page covers it.

Truncate first

There is a truncate first option. It empties the target tables before writing, which is what you usually want for a repeatable staging refresh.

If a truncate would cascade into tables you did not select, SeedQL stops and tells you which ones rather than quietly deleting them. You then confirm explicitly. This is deliberate: a cascade that surprises you in staging is annoying, and the same habit applied to the wrong connection string is not.

Large pushes

Above roughly 100,000 rows, SeedQL runs the push as a background job instead of holding the request open. You get a progress view and can close the tab; the job keeps going.

Jobs can be cancelled. Cancellation stops at the next safe checkpoint rather than mid-write, so you do not end up with half a table.

What SeedQL never does

It does not read your existing rows. Introspection reads structure only: tables, columns, types, keys. No production data is copied, sampled or sent anywhere, which is the whole point of generating rather than cloning.

It does not retain generated data either. Rows are streamed to your target and not stored by SeedQL, which is why there is no way to fetch a past generation's data back. What is kept is the record of the run: how many rows, which tables, the seed, when.

Row limits

Each plan has a per-request cap and a monthly total.

Plan	Rows per generation	Rows per month
Hobby	5,000	5,000
Pro	100,000	100,000
Business	500,000	500,000
Enterprise	10,000,000	effectively unlimited

Hitting a cap stops the request before anything is generated, so you are never billed rows you did not receive. Usage in the sidebar shows where you are.