Design your data model
in minutes, not hours

Describe the data you want in a sentence and you get tables, columns with real field types, and the foreign keys already drawn, open in the editor and yours to change. Two things happen after your description is read that are worth knowing. A column that came back as plain text but is named first_name, product_name or username is switched to that field type, so it generates names rather than random text. And no column is made nullable unless you make it: a request for realistic data tends to come back with invented missing-value rates, and those are reset to zero so nullability stays a decision you make per column. If the tables include state, city and postal code, those three are wired to the same reference data before you ever see them, so the values agree.

SQL and your own CSVs. Paste CREATE TABLE statements and the importer reads tables, columns, primary keys and single-column foreign keys across the same seven SQL dialects it generates for. A MySQL ENUM or SET column arrives as a fixed value list, so the generator only draws from the values you declared, and server-side defaults like NOW() or gen_random_uuid() are dropped, because neither means anything for a generated row. Or upload a CSV sample and the column types are read off your own values. Send several files to the API and the relationships between them are worked out as well: a column becomes a foreign key only when every sampled value in it is found in the other column, and only when the name points at that table or the values cover at least half of it, so a quantity of 1 to 5 is not turned into a reference to an id just because the numbers fit. JSON Schema and MongoDB collection import are not built.

No, and the editor marks it as an error while you are still editing rather than letting the job fail later. Tables are written parents first, and a table that references itself has no position in that order. Model the hierarchy as a separate table holding both sides of the link: reporting_lines.employee_id and reporting_lines.manager_id, both pointing at employees.id. That table is also where a link gets its own columns, like the date somebody started reporting to somebody else, which a manager_id column has nowhere to put.

The model you design is relational: tables, columns, foreign keys. What changes is what comes out of it. For SQL you get a CREATE TABLE script per dialect plus the bulk loader that dialect wants. For MongoDB, ask for the nested JSON output and each child row is embedded inside its parent document, grouped by the foreign key, with the tables that are nobody's child as the top-level documents; the JSONL version of the same thing is one document per line, which is what mongoimport reads. Flat JSON and JSONL per table are there too when you would rather load each collection separately.