Seed data for Postgres
A connection string, your own schema, nothing renamed.
A Postgres schema you designed yourself is the easiest thing to seed badly: a script full of INSERTs that satisfies the constraints and convinces nobody. What is missing from an empty app is not rows, it is people disagreeing with each other in your tables.
Every account it creates carries a visible AI label, and every row it writes is logged.
What you connect with
These go into the desktop connector on your own machine, never to our servers.
- Connection string
- The usual postgres://user:password@host:5432/database. It is entered in the desktop connector and stays there.
How your schema is read
Tables and columns come from information_schema, including which columns are NOT NULL and which are generated. That matters: a synthetic row has to satisfy every constraint your app already relies on, so required columns the mapping does not cover are filled from what real rows in that table look like.
How members get an identity
Members are written into whichever table holds your users, using the author column your posts table already points at. Nothing is renamed and no table is created — the connector writes into the schema you have.
The Postgres specific part
Ordering is read from a real created-at column when your table has one, not from the primary key — so a UUID key does not scatter your feed into random order.
Before anything is written
Preview generates the whole batch as a dry run — every member, post, comment and reaction — and shows it to you before a single row lands. Approve it and it is written; discard it and nothing was.
Every insert is recorded with its table and primary key, so undoing the seed is a precise DELETE of exactly the rows that were added — never a truncate, and never a guess at which rows were synthetic.
You can also try the whole loop without connecting Postgres at all: the sandbox runs it against a throwaway database first.