The questions engineering teams ask when they evaluate Seedfast, answered in one place. Each answer links to the documentation page that backs it.
Where the product starts and stops, and what a run looks like from the terminal.
Seedfast works at the database level, reading the schema and writing rows into the tables. Anything your own application builds out of those rows comes out coherent as a side effect, because the rows are. An invoice your code renders from seeded orders, line items and payments reads as one consistent document, since every record it draws on was generated to fit the records around it.
A run takes three commands. seedfast login opens a browser once and stores credentials on the machine, seedfast connect takes a connection string, and seedfast seed reads the schema, proposes a plan and, once you approve it, writes the rows. Pass --scope "..." and the prompt is skipped, which is how the same command goes into a script or a CI job. Every operation is also exposed as an MCP server, so an assistant such as Claude or Cursor can run a seed as a tool call without anyone opening a terminal.
Before a single row lands, Seedfast shows the plan it built from your schema and scope, listing the schemas and tables it will fill and the row count for each. You approve it, or you type what you would change (double the invoices, skip audit_logs) and it replans inside the same session, as many times as it takes. In --scope mode the plan is applied without the prompt, and a scope that is ambiguous or leaves a dependency unresolved stops with an error rather than guessing, because nobody is at the terminal to answer.
No. Run seedfast seed with no scope and Seedfast proposes one from the schema alone, picking a coherent set of tables and row counts that suit its size. Writing a scope becomes worth doing once you care about the particulars, and since it is plain text it can come from anywhere. It can live in the repository next to the migrations, and an AI agent that already knows your codebase can draft it from the schema and the documents you have, then hand it to Seedfast over MCP and run it. Most scopes are a sentence or two, and the long brief is reserved for a business that really is that complicated.
Most tools in this space start from one of two places. Masking and synthesis products start from production, which means they need access to it, weeks of setup and an enterprise contract before the first row appears. Column-level generators such as Faker or a web form start from nothing and leave the relationships, the counts and the domain to you, which works for one table and a script nobody maintains after the third migration. Seedfast starts from the schema and a description of the business, and produces a database that reads as that business, connected and sized as you asked, without ever seeing production. It runs as one CLI command, as an MCP tool for an AI agent, or as a pipeline step, and the pricing is public, with a free plan and no per-row or per-token metering. Where a specific product is on your shortlist, the comparison pages go through it tool by tool.
How much data comes back, in what shape, and in which language.
The counts are yours to set, and they are never copied from production, because Seedfast does not read production in the first place. State them in the scope (500 products, 5,000 orders, 4,200 supplier invoices) and the plan carries those exact figures, which the seeded tables then match. Ratios work the same way (100 customers, each with 5 to 10 orders), as do schema-level targets (all tables in the billing schema, 500 rows each). A hundred rows for a unit test and tens of millions for a load test are the same command with a different sentence, and the plan preview shows the resulting per-table counts before you commit to either.
By default Seedfast shapes the data the way a live system would look rather than filling columns uniformly, so status columns come out skewed, order totals long-tailed, timestamps clustered into business hours, and table sizes proportioned to one another. Where you know the numbers, you write them down and the plan follows them exactly, whether that is row counts per table, ratios between tables, or shares across a status column (60% paid, 25% overdue, 15% disputed). Where you only know the shape, describing it in words is enough, and a scope that asks for customer ages centred in the mid-thirties or for a lighter weekend than weekday comes back looking that way.
A statistical replica of your production data is a different thing, and Seedfast does not produce one. It never sees production, so it cannot preserve the joint distribution of a specific real dataset for a model to train on. If that is the requirement, you are looking for a masking or synthesis product that starts from production rows, and Seedfast sits on the other side of that line on purpose.
Localized data is the normal case rather than a special mode. The scope can be written in any language, and generated values follow whatever locale you name, so asking for customers in Arabic produces Arabic personal names, company names that fit the market, and phone numbers on the right country code, rather than English data with the strings swapped out. A platform that was built around English and now needs to demo in Arabic, German or Spanish does not have to translate anything. It asks for the records it wants in that language and gets them shaped the way names and addresses are shaped there. When a naming convention matters, put it in the scope, either as a pattern to follow or as a handful of examples, and use the plan preview and a query afterwards as the check.
Seedfast has no per-industry templates and no vertical it was tuned to. It works out what the data represents from the schema in front of it, reading table names, column names, types and constraints, so a patients table with diagnosis_code and attending_physician_id gets medical values and an orders table gets an order lifecycle, with no configuration in between. Whatever the schema cannot say, the scope can. The few paragraphs you would give a new analyst on their first day, describing what the business does and what its records look like, are exactly what Seedfast takes as its brief, in any domain and in any language.
What Seedfast needs from a schema, and what it promises about the rows it writes.
Today Seedfast reads the schema over a live connection, and that is deliberate, because dumping a schema, sending it somewhere and importing the result is the workflow it exists to remove. The database it reads does not have to be anything sensitive. An empty local Postgres in Docker with your migrations or DDL applied is enough, since Seedfast needs the structure and not the rows, and the connection string never leaves your machine. Production is never the database you point it at.
Seedfast takes the schema as it finds it. It does not ask you to clean up normalization first, and it does not build an idealized model of what the schema should have been. Its guarantee covers everything the database itself enforces, so every declared foreign key points at a row that exists, check constraints and enums hold, unique constraints hold, and rows insert on the first attempt with nothing to clean up. A relationship that lives only in convention, such as a customer_ref text column that happens to hold customer codes, is invisible to the database, so describe it in the scope and verify it afterwards with a query, because the database cannot verify it for you. The surest route, since the database you seed is never production, is to declare the constraint there before seeding, at which point it is enforced rather than described.
Seedfast handles foreign keys, composite keys, multi-level dependencies, check constraints, unique constraints, enums, JSON columns and triggers. When a trigger fires on insert, the seeded state reflects what the trigger did and not only the raw rows, which matches how your application writes. Circular foreign-key references are handled as well, including cycles that are NOT NULL on both sides. Several Postgres schemas in one database can be filled in a single run.
A new table does not need a full reseed. Seedfast reads the live schema on every run and only touches the tables in the scope, appending rows and leaving existing ones alone, so two hours after the first seed you can add a table, run a scope that names just that table, and the new rows are generated against the parent rows already in the database. Renamed columns and added foreign keys are picked up the same way, with nothing to update for changes that do not affect what you are seeding, and if a change does break the scope Seedfast tells you before writing anything. A new column on an already populated table is the case it does not cover today. Seedfast does not rewrite existing rows, so backfilling that column means truncating the table and seeding it again.
Volume is part of the scope rather than a separate setting, and it runs from a handful of rows for a local branch to tens of millions when tables need to weigh what production weighs, which is enough to reproduce the working set of a large, high-traffic product where index choices start to matter. Width is not a ceiling either, since a single run covers schemas of hundreds of tables, spread across several database schemas when that is how the database is laid out, and the plan preview lists every table it will touch before anything is written.
PostgreSQL, including Supabase, Neon and Amazon RDS. We went PostgreSQL-first because it has the richest constraint and relationship system, which is exactly where realistic seeding gets hardest. Support for other SQL engines, including MySQL, Oracle and SQLite, is in development.
Which parts of a run stay on your side of the network, and which do not.
The CLI runs on your machine or in your pipeline and holds the database connection, so credentials stay local and the rows are written from there. What travels to Seedfast is schema metadata, meaning table and column names, types, constraints and relationships, because that is what generation is planned from, and the generated values then come back to be inserted. Production data never enters the workflow, since the database you connect is a development, CI, staging or demo instance, and nothing in it is read as source material. That is why we say no production access is required rather than calling the workflow compliant, since the schema itself does leave your perimeter, and a security review that covers how the schema is handled is something we walk through on request.
Run times, why they matter inside a pipeline, and where the prices live.
A single table lands in seconds, a handful of related tables in under a minute, and a full schema of fifty or more tables in a few minutes, with the planning phase growing with the width of the schema rather than the row count. The interactive session stays open across replans, so refining the scope costs a rerun of the plan and not a fresh login and connection. If a run takes longer than expected, narrowing the scope to the tables the task actually needs is the first thing to try.
For a database you seed once and keep, speed barely matters, and it starts to matter the moment seeding sits inside a loop. A CI pipeline that stands up a fresh database for every branch and every pull request seeds on every run, and at that cadence the gap between a few minutes and half an hour is the gap between a step nobody notices and a step that gets skipped. Migrations are the other trigger, because every one that lands means the old data no longer fits, and a team shipping several a week reseeds several times a week. A demo or review environment is the same loop at a slower pace, starting empty each time it is stood up.
A seeding run has two phases, scoping, where Seedfast reads your schema and works out what to generate, and the generation itself. Current prices are on the pricing page, which is the only place we quote them, because the figures move as the engine gets cheaper to run. Every plan works from a monthly pool of credits that a run draws on, with no table or seed limits and no per-row or per-token metering. Lowering what a run costs a customer, measured against what the alternatives charge for the same result, is ongoing work on our side, and the pricing page reflects it as it lands.
An LLM handed a schema and asked for rows produces something that looks right in a small sample and comes apart at scale, with counts drifting from what was asked, references pointing at rows that were never written, and every schema change meaning a fresh prompt from scratch. Seedfast uses AI as the primary planner, but the plan is validated against the schema before anything is written, the counts you set are the counts you get, and the database accepts the result on the first insert, whether that is fifty rows or fifty million.
Who reaches for Seedfast, and why.
Engineers, testers and product people who need a database that behaves like production without being allowed, or able, to copy it. That covers teams in finance, healthcare and other settings where production data cannot enter a development environment, teams with no production data yet because the product has not launched, and distributed or outsourced teams that policy keeps away from it. The schemas that make it worth paying for tend to be the wide ones, twenty tables and up, where a hand-written seed script has turned into a maintenance job of its own. Agencies and product studios feel this hardest, since every new client project starts another empty system.
A question this page does not answer is one we would like to hear. Send it over and it will be answered directly, and added here if it is one other teams will ask too.
Generate realistic synthetic data from your database schema.Safe, coherent, and ready for local dev, demos, and CI.
