JSON to SQL Converter

JSON already carries types, so nothing has to be guessed. In CSV every value is text and the converter has to decide whether 42 is a number or a string, whether true is a boolean, and whether 007 is a code — all inference, all occasionally wrong. In JSON those distinctions are already in the document, so a number is emitted unquoted because it genuinely is a number, and a string of digits stays quoted because the source said it was a string. The generated types are correspondingly more trustworthy.

They are flattened into columns joined by an underscore, so an address object containing a city becomes an address_city column. A relational table has no nesting, so the alternatives are flattening, storing JSON in a single column, or splitting into related tables — and only you know which your schema wants. Flattening is the useful default for a one-off load; if the nesting is deep or genuinely relational, the flattened column names will make that obvious quickly.

By default they become a JSON string in a single column, which is what you want if the target has a JSON column type — Postgres and modern MySQL both do, and storing it that way keeps the structure intact and queryable. The alternative is joining them into a delimited string, which is easier to read and harder to query reliably once a value contains the delimiter. Neither is right for genuinely relational data; that wants a second table and a foreign key.

Yes, and this is common in real API responses. Every key seen anywhere across the array becomes a column, and a record missing that key gets NULL for it. The tool reports how many records were incomplete, because a high number usually means the array holds more than one kind of record — and a single table is the wrong shape for that, however cleanly it converts.

The escaping is correct for producing valid SQL literals — single quotes are doubled — but correct escaping is not the same as being injection-safe, and the distinction matters. These statements are for loading data you already have and trust, run once by you against your own database. Never generate queries this way from user input at runtime: use bound parameters, which separate the query from the data entirely instead of relying on escaping being right every single time.

As a starting point to edit, not as a finished schema. It has no primary key, no indexes, no foreign keys and no NOT NULL constraints, because none of those can be inferred from a data sample — they are design decisions. The column types are more reliable here than from CSV, since JSON already declares them, but a VARCHAR sized from the longest value you happened to sample will be too small the first time a longer one arrives.