Conversor gratuito de SQL para JSON

Sobre a conversão SQL → JSON

Esta ferramenta analisa as instruções SQL CREATE TABLE e as converte para o formato schema JSON. Ela extrai nomes de colunas, tipos de dados (INT, VARCHAR, TEXT, BOOLEAN, DATE, TIMESTAMP, DECIMAL) e restrições (NOT NULL, PRIMARY KEY, valores DEFAULT). A saída JSON serve para documentação de API, design de banco de dados ou ferramentas de migração.

Tipos de dados SQL suportados

• INT / INTEGER · valores inteiros de 32 bits
• VARCHAR(n) · texto de comprimento variável com comprimento máximo
• TEXT · texto de comprimento ilimitado
• BOOLEAN / BOOL · valores verdadeiro/falso
• DATE · datas de calendário sem hora
• TIMESTAMP · data e hora com suporte a fuso horário
• DECIMAL(p,s) · números decimais precisos

Perguntas frequentes

Quais dialetos SQL são suportados ?

Este conversor gerencia a sintaxe SQL padrão usada pelo MySQL, PostgreSQL, SQL Server e SQLite. Recursos específicos de um dialeto podem não ser totalmente reconhecidos.

Ele lida com restrições complexas ?

O conversor reconhece NOT NULL, PRIMARY KEY, DEFAULT e as informações de tipo básicas. Restrições complexas como CHECK ou FOREIGN KEY são armazenadas como anotações em texto.

Posso usar a saída JSON diretamente ?

Sim ! A saída JSON é formatada para a legibilidade e pode ser usada em schemas de API, interfaces TypeScript ou geradores de documentação.

Schema, not data, what this tool does

This converter takes a SQL CREATE TABLE statement and emits JSON Schema: a description of the columns, types and basic constraints, suitable for API contracts, TypeScript-type generation, and document-store migrations. It does not convert INSERT rows or query result sets to JSON. Search interest in "SQL to JSON" splits roughly in half between those two needs; if you've arrived expecting row-to-object conversion, you'll want a different tool. The schema-conversion path is the developer-facing case: you have a table definition and want a structured description of its shape that another tool can consume.

A short history of SQL

SQL was designed at IBM's San Jose Research Laboratory in the early 1970s by Donald D. Chamberlin and Raymond F. Boyce. The original name was SEQUEL: Structured English Query Language, conceived as a higher-level interface to IBM's experimental relational database System R. The relational model itself had been published in 1970 by Edgar F. Codd; Chamberlin and Boyce's contribution was a syntax that ordinary analysts could read, modelled on natural English clauses (SELECT … FROM … WHERE …) rather than on Codd's algebraic symbols. Boyce (who would also lend his name to Boyce-Codd Normal Form) died in 1974 at age 26, before the language he co-invented saw commercial release. The name was changed to SQL in 1975 because of a trademark conflict with Hawker Siddeley's SEQUEL trademark, although the original "sequel" pronunciation persists in the United States alongside the international "ess-cue-ell."

ANSI standardised SQL in 1986 (SQL-86), ISO ratified an essentially identical version in 1987 as ISO/IEC 9075, and the standard has been revised every three to five years since: SQL-92 (still the baseline most tutorials assume), SQL:1999 (recursive queries, triggers), SQL:2003 (XML type, MERGE), SQL:2011 (temporal tables), SQL:2016 (JSON support), and most recently SQL:2023 (multi-dimensional arrays, property graph queries). Despite waves of competing technologies (object databases in the 1990s, NoSQL in the late 2000s, data lakes in the 2010s) SQL has persisted as the dominant query language for structured data for over fifty years. By 2024, even most NoSQL platforms have reintroduced SQL or SQL-like layers (Cassandra's CQL, MongoDB's $sql aggregation stage, DynamoDB's PartiQL, Spark SQL, Trino, DuckDB, BigQuery, Snowflake), confirming Mike Stonebraker's prediction that the language would outlive any single storage engine.

JSON in one paragraph

JSON (JavaScript Object Notation) was specified by Douglas Crockford in 2001, derived from a subset of JavaScript object literal syntax, and standardised as ECMA-404 in 2013 and IETF RFC 8259 in 2017. It has only six value types (string, number, boolean, null, array, object) and no native concept of dates, decimals, binary, or schemas. JSON Schema (a separate specification, currently at draft 2020-12) layers structural and type validation on top. The value of JSON Schema for this converter: it's a portable, schema-agnostic format that almost every modern code-generator and validation library understands.

The mechanical conversion

A representative input:

CREATE TABLE users (
  id INT PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  signup_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  is_active BOOLEAN DEFAULT TRUE
);

Maps to:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "users",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "maxLength": 255 },
    "signup_at": { "type": "string", "format": "date-time" },
    "is_active": { "type": "boolean", "default": true }
  },
  "required": ["id", "email"]
}

Step by step: tokenise the input, locate CREATE TABLE and the table name, find the parenthesised column list, split column definitions on top-level commas (respecting nested parentheses for things like DECIMAL(10,2) or CHECK (x > 0)), parse each column into name + type + modifiers, and map the SQL type to the closest JSON Schema type. NOT NULL becomes membership in the required array. DEFAULT becomes a default value. PRIMARY KEY usually becomes an annotation or membership in required. CHECK, FOREIGN KEY, UNIQUE and indices typically become text annotations because JSON Schema has no direct equivalent.

The dialect problem

SQL is famously a family of dialects, not a single language. Even basic identifier quoting differs:

• MySQL / MariaDB: backticks: `column_name`.
• PostgreSQL and the SQL standard, double quotes: "column_name".
• SQL Server / MS Access: square brackets: [column_name].
• SQLite: permissive, accepts all three.

Type names diverge too. INT(11) in MySQL is a display-width hint that PostgreSQL rejects. SERIAL in PostgreSQL is shorthand for INT NOT NULL AUTO_INCREMENT PRIMARY KEY; IDENTITY fills the same role in SQL Server; SQLite uses AUTOINCREMENT. BOOLEAN is TINYINT(1) under the hood in MySQL. Geographic types (GEOMETRY, POINT), JSON column types (JSON, JSONB), array types (PostgreSQL's INTEGER[]) and full-text vector types (VECTOR(1536) in pgvector) have no JSON Schema equivalent and end up as opaque string annotations. BLOB and BYTEA binary data has no native JSON representation; standard practice is base64-stringification with a contentEncoding hint.

SQL types vs JSON types, the impedance mismatch

SQL has a rich type system; JSON has six value types and no schema. Worth knowing:

• Numeric types: INT, BIGINT, SMALLINT, TINYINT all collapse to JSON number. JavaScript and most JSON parsers use IEEE 754 double-precision, which only represents integers up to 2^53 exactly. BIGINT values above that lose precision when round-tripped through JSON parsers. Some pipelines serialise BIGINT as a quoted string to preserve precision; that's a known JSON-API design pattern.
• Decimal / numeric: DECIMAL(10,2) for money is an exact-precision type in SQL but becomes a lossy floating-point JSON number unless serialised as a string. Financial APIs almost always serialise money as decimal strings ("19.99") for this reason.
• Date / time / timestamp: JSON has no native temporal type. The standard convention is ISO 8601 strings ("2026-05-02T14:30:00Z"), with JSON Schema's { "type": "string", "format": "date-time" } annotation. TIMESTAMP WITH TIME ZONE in PostgreSQL preserves zone information; TIMESTAMP WITHOUT TIME ZONE doesn't, round-tripping through JSON usually flattens the distinction.
• Booleans: straightforward true / false mapping. SQL Server's BIT often comes through as 1/0; this converter normalises to true/false.
• NULL: JSON null. Worth noting that the absence of a key ({}) is semantically distinct from an explicit null ({"x": null}) in most JSON consumers.
• Enums: SQL ENUM('a','b','c') maps cleanly to JSON Schema {"enum": ["a","b","c"]}.

When you'd reach for this

• Generating OpenAPI / Swagger schemas from existing database tables for an API that returns the same shape.
• Bootstrapping TypeScript / Zod / io-ts types: once you have JSON Schema, tools like quicktype or json-schema-to-typescript produce type definitions automatically.
• Migrating SQL → MongoDB / Firestore / DynamoDB: the first artefact you usually want is a list of document shapes; JSON Schema is a clean intermediate format for that planning exercise.
• Frontend mocking: front-end engineers building against a backend that doesn't yet exist need a JSON description of the row shape so they can generate fake data with faker.js, MSW, or json-server.
• Internal data-dictionary documentation: DBT model docs, design wikis, schema-as-code repositories all consume JSON descriptions of table shapes.
• Test fixture generation: property-based testing libraries (hypothesis, fast-check) and factory libraries need a description of the expected shape to generate satisfying test data.

Modern alternatives

• Database-native JSON output. PostgreSQL has row_to_json(), json_agg() and the jsonb_ family; MySQL has JSON_OBJECT() and JSON_ARRAYAGG(); SQL Server has FOR JSON. If you control the database you can usually skip a converter entirely and emit JSON straight from the query.
• ORM introspection. Prisma, Drizzle, SQLAlchemy, TypeORM, Sequelize-auto and similar libraries can introspect existing tables and emit type definitions or schema files in their own formats, often closer to what you actually want than raw JSON Schema.
• Schema-as-code tools. Atlas (HCL), Liquibase (YAML), Sqitch (SQL), and DBML (Database Markup Language) describe table shapes in their own DSLs that have richer constraint vocabularies than JSON Schema.

More questions

What if my CREATE TABLE has FOREIGN KEY constraints?

JSON Schema doesn't have a native foreign-key concept. The cleanest representation is a custom annotation (e.g., a non-standard x-foreign-key property) noting the referenced table and column. This converter preserves the relationship as a text note in the output; if you need fully-formal reference modeling, JSON Schema's $ref + a separate definitions block is the closest fit, but it's awkward for many-to-many cases. For richer relational modeling consider DBML or Atlas HCL.

Why doesn't the output include CHECK constraints?

JSON Schema can express many simple CHECK constraints, CHECK (age >= 0) becomes {"minimum": 0}, CHECK (status IN ('a','b')) becomes {"enum": ["a","b"]}: but arbitrary SQL expressions in CHECK clauses (function calls, joins, subqueries) have no JSON Schema equivalent. The converter recognises the simple cases and preserves complex constraints as text annotations rather than silently dropping them.

Can I convert INSERT rows to JSON?

Not with this tool, it only handles schema-level conversion (CREATE TABLE). For row-level conversion, the right approach is usually database-native: PostgreSQL's SELECT row_to_json(t) FROM tbl t, MySQL's JSON_OBJECT(), or exporting to CSV and using a CSV-to-JSON tool. mysqldump --xml piped through an XML-to-JSON converter is another well-trodden path.

Why is BIGINT a problem in JSON?

JavaScript's JSON.parse uses IEEE 754 doubles, which can only represent integers up to 2^53 = 9,007,199,254,740,992 exactly. Numbers above that lose precision. SQL BIGINT goes up to 2^63 ≈ 9.2 quintillion, well beyond the safe JSON integer range. The cross-platform convention for safely transporting BIGINT through JSON is to serialise it as a string and parse with BigInt at the destination; many APIs (Twitter / X's tweet IDs, Stripe IDs, PostgreSQL's bigserial) do exactly this.

Does anything get sent to a server?

No. The parser runs in your browser; the JSON output is built locally. Pasted SQL never leaves your device, which matters if your CREATE TABLE statements contain proprietary column names, internal table conventions or other details you don't want logged. The page works offline once it's loaded.

Ferramentas relacionadas