Fill tables with test data

Fill tables with realistic rows in one click: names, e-mails, prices and dates that respect your types, constraints and foreign keys, plus sign-in users, and remove them again.

Test data fills the tables you choose with rows that look real, so you can try your app, demo it or check a query on more than three rows. The values fit what each column is for (names in name columns, e-mails in e-mail columns, prices, dates spread over the past year, addresses, product names) and follow your schema:

• Types and lengths: a varchar(12) gets 12 characters at most, integers stay in range, arrays and JSON get matching values.
• Constraints: required columns are filled, unique columns get unique values, enums and CHECK (status in (…)) lists use the allowed values, and simple ranges such as CHECK (rating between 1 and 5) or char_length(note) <= 40 are respected.
• Foreign keys: tables are filled parents first, and every foreign key points at a real row — one this run added or one that was already there. A one-to-one key (a profiles row per user) uses each parent once.
• Defaults: identity and serial ids, generated columns and columns with a default (for example a UUID id) are left to the database, except dates, flags and allowed-value columns, which get varied values.

#Add test data

1. Open Studio › Database › Test data.
2. Tick the tables to fill and choose how many rows each, or pick a size (Small: 10, Medium: 100, Large: 1,000 rows per table).
3. Optionally create sign-in users: confirmed e-mail users at @example.com (never e-mailed) with one test password, so you can sign in as them. Tables that point at auth.users use these users.
4. Preview shows the first rows of each table. Add test data adds the same rows (the preview's seed is reused).

Everything is added in one transaction: if something fails, nothing is left half done. A row that breaks a rule the generator could not read (a check with a function in it, a trigger that raises an error) is skipped and listed with the reason; the rest go in.

#Options

#Remove test data

Every run is listed under Runs with what it added. Remove deletes exactly the rows that run added, children before parents, and the sign-in users it created. Rows you added yourself stay. If rows you added later point at test rows (an order of yours that uses a test product), nothing is removed and the message says which foreign key is in the way. Rows of tables without a primary key cannot be removed this way.

Which rows belong to a run is kept in the _stitch_testdata schema of your database. Test users carry test_data: true in their app metadata.

#Limits

Up to 100,000 rows per table and 10,000 sign-in users per run, within your plan's rows per run: