Seed data for MongoDB
Documents that carry their own plausible fields, not empty slots.
A Mongo collection will happily accept a document that your own app then refuses to render, because the query filters on a field the document does not have. That is why seeding a document store by hand is so unsatisfying: the data is there and the screen is still empty.
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 URI
- mongodb+srv://… or mongodb://…, entered in the desktop connector.
- Database name
- Which database inside the cluster to write to.
How your schema is read
A collection has no schema to read, so the connector samples the documents that are already there and learns the shape from them — which fields exist, which are enums, which are timestamps, which your app filters and sorts on.
How members get an identity
Members are written as documents in your members or profiles collection, and posts reference them the way your existing documents do.
The MongoDB specific part
The interesting part of a schemaless store is the fields nobody mapped. A post document in your app might need status, category or a short description before your own queries will show it. Those free-form fields are written by the model in the persona's voice — so a synthetic document is plausible on its own terms, never a copy of a real user's values.
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.
Documents written by the seed carry their own ids in the ledger, so removing it deletes exactly those documents — the collection your users write to is untouched.
You can also try the whole loop without connecting MongoDB at all: the sandbox runs it against a throwaway database first.