Values are inlined as literals with quotes escaped — fine for seeding and fixtures, but use parameterised queries for anything driven by untrusted input.
Getting a JSON export into a database usually means writing the DDL by hand. This infers column types from every row rather than the first — a column holding 1, 2 and 3.5 becomes decimal, and a column that is ever missing or null becomes nullable — then emits a CREATE TABLE and the INSERT statements to load it, quoted correctly for your dialect.
PostgreSQL, MySQL, SQL Server and SQLite, each with correct quoting, types and boolean literals.
A column holding 1, 2 and 3.5 becomes decimal; a column ever missing becomes nullable.
Table definition and the statements to load it, chunked for large sets.
Objects and arrays are stored as JSON text columns, which is what these databases want anyway.
PostgreSQL, MySQL, SQL Server and SQLite. Identifier quoting, boolean literals and type names follow each dialect — JSONB for Postgres, JSON for MySQL, NVARCHAR(MAX) for SQL Server, TEXT for SQLite.
They are stored as JSON text in a single column, which is what all four databases would have you do anyway. Flatten them first with the CSV tool if you want separate columns.
Values are inlined as escaped literals, which is fine for seeding and fixtures. Do not build a pipeline that inlines untrusted input this way — use parameterised queries for anything user-driven.