Uma coluna do SQLite aceita qualquer tipo: como tirar os dados do banco sem perder o tipo de cada valor

A Cloudflare publicou em outubro de 2026 como reorganizou o plano de controle do D1, o banco SQL serverless dela, para atender milhões de bancos. O D1 é construído sobre SQLite. Segundo o texto, plataformas de desenvolvimento assistido por IA empurram as aplicações para muitos bancos pequenos, um por usuário, por aplicação, por ambiente de teste ou por cliente. A cobertura da InfoQ, publicada em novembro, informa que o número de bancos ativos por dia cresceu 18 vezes em um ano.

Quando um sistema tem centenas de bancos SQLite espalhados, a pergunta deixa de ser onde o dado está. Passa a ser como ele sai de cada banco e volta sem perder o tipo. É nesse ponto que o SQLite costuma enganar quem trabalha com ele.

Uma coluna do SQLite aceita qualquer tipo

A documentação oficial do SQLite diz que o tipo pertence ao valor e não à coluna. Só a chave inteira primária fica de fora dessa regra. Qualquer outra coluna aceita valores de qualquer classe de armazenamento: NULL, INTEGER, REAL, TEXT ou BLOB. O tipo declarado na tabela é uma recomendação, chamada afinidade, e não uma obrigação.

Isso aparece em sistemas reais de duas formas. Um mesmo campo pode ter texto em uma linha e número em outra. E datas, que o SQLite não tem como classe própria, ficam como texto, número inteiro ou número real, conforme quem gravou.

A afinidade também mexe com números que parecem texto. Quando um texto com cara de inteiro entra numa coluna declarada INTEGER ou NUMERIC, ele vira número. Num CPF com zero à esquerda, isso pode apagar o zero. O dado que mais precisa ficar exato é justamente o que sofre com a conversão.

O caminho comum costuma perder o tipo

O caminho mais usado é exportar a tabela para CSV ou JSON, importar em outro lugar e torcer para os tipos baterem. O AGENTS.md do jsonW, escrito para agentes de código, pede o contrário: não exportar para CSV ou JSON no meio do caminho, porque esse formato perde o tipo, o zero à esquerda e a precisão.

Como fazer a ida e a volta, passo a passo

O jsonW tem um conector para bancos chamado wcon. Para o SQLite, o README mostra duas operações: uma leva a consulta para um arquivo .jsw e a outra devolve o arquivo para uma tabela.

wcon sqlite banco.db "<sql>" saida.jsw
wcon sqlite-gravar arq.jsw banco.db tabela

Um exemplo com uma tabela de clientes, tirado do AGENTS.md:

wcon sqlite app.db "select * from clientes" clientes.jsw
wjsw conferir clientes.jsw
wcon sqlite-gravar clientes.jsw app.db clientes

O processo tem três passos:

1. Extrair: a consulta sai do banco e vira um arquivo .jsw. O esquema não é escrito à mão. Segundo o README, o tipo de cada coluna sai da classe que o SQLite guardou em cada valor, e não do conteúdo do texto.
2. Conferir: o comando wjsw conferir valida o arquivo com sha256 e crc32c antes de qualquer volta.
3. Voltar: o wcon sqlite-gravar grava tudo em uma transação só. Se a tabela não existir, ela é criada.

O fluxo completo, do banco ao arquivo e de volta ao banco:

flowchart LR
    A["app.db (SQLite)"] --> B["wcon sqlite"]
    B --> C["clientes.jsw"]
    C --> D["wcon sqlite-gravar"]
    D --> E["app.db, tabela clientes"]

Vantagens concretas para quem decide

• Tipo que sobrevive: o dinheiro guarda a moeda ISO 4217 em cada valor; o decimal exato não passa por ponto flutuante; o tipo codigo guarda bytes exatos, como CPF, SKU e chave.
• Data sem susto: DATE e DATETIME do SQLite ficam como texto de propósito. Sem fuso no banco, converter para meia-noite UTC poderia trocar o dia.
• Custódia: crc32c e SHA-256 em cadeia. Qualquer byte trocado falha na conferência.
• Permissão no arquivo: colunas marcadas como pessoais ou por escopo saem nulas para quem não tem o escopo.
• Escrita segura: os valores viajam como dados com parâmetro ligado, nunca montados dentro do comando. A volta é uma transação só.

Comparação honesta com o que se usa hoje

O CSV e o JSON exigem refazer os tipos à mão depois da importação. O arquivo .jsw guarda os tipos junto com os dados. Mas o jsonW não substitui o SQLite. Segundo o README, ele não pede que você troque de banco. O arquivo serve para levar, arquivar, consultar e conferir os dados, enquanto o SQLite segue como banco da aplicação.

Há um limite de plataforma. O README informa que o wcon sai para macOS e Linux, e que no Windows ele roda pelo WSL.

Economia e velocidade: o que está medido

O README publica dois números: o arquivo fica 4,9 vezes menor que o JSONL dos mesmos dados, e a leitura de um campo de uma linha fica 3.281 vezes mais rápida. Os dois valem para 100 mil registros, comparados com JSONL lido pelo leitor de JSON do próprio projeto. Nenhum deles compara com SQLite.

O README também não traz números de custo, de memória ou de servidor para o caminho SQLite. Por isso este texto não estima economia de servidor. Para medir no seu caso, o README indica o comando wjsw medir, que roda na sua própria máquina.

Na parte de recursos, o README descreve mecanismos sem número. A leitura de um campo não decodifica o resto do arquivo. Em arquivo remoto, o wremoto baixa só os blocos das linhas consultadas, por HTTP Range.

Liberdade funcional e licença

Segundo o README, o núcleo em C não tem dependências além da biblioteca padrão. A licença de uso sustentável libera o uso dentro do seu produto, em quantos servidores você quiser. Não vale revender o jsonW como serviço nem fazer engenharia reversa do núcleo. A documentação pode ser lida e usada para criar programas que usem o jsonW.

A Wortic usa o jsonW no índice dos seus agentes e nos seus modelos de IA, conforme o README. Se o seu sistema guarda dados em SQLite e precisa levá-los para análise ou para outro banco sem mexer nos tipos, o caminho começa com um arquivo de amostra e o wcon. Para acordo comercial ou outra plataforma, o contato está em wortic.com.br.

Perguntas frequentes

Dá para tirar dados de um SQLite e devolver sem perder o tipo?

Sim, com o wcon. A ida gera um arquivo .jsw e a volta grava de novo na tabela. Segundo o README, a ida e a volta não perdem dados. Antes de voltar, rode o conferir para validar o arquivo.

Por que uma coluna do SQLite pode misturar texto e número?

Porque o tipo pertence ao valor, e a coluna apenas recomenda um tipo. Pela documentação do SQLite, qualquer coluna, exceto a chave inteira primária, aceita valores de classes diferentes.

O jsonW substitui o SQLite?

Não. O jsonW não pede que você troque de banco. Ele leva os dados para um arquivo e devolve ao banco, e o SQLite continua sendo o banco da aplicação.

O zero à esquerda de um CPF se perde na volta?

No jsonW, o tipo codigo guarda os bytes exatos, e o AGENTS.md indica o CPF como caso desse tipo. A perda costuma começar antes, na afinidade do SQLite: um CPF com zero à esquerda, gravado como número numa coluna INTEGER ou NUMERIC, pode perder o zero. Por isso, o caminho mais seguro é declarar essa coluna como texto.

Funciona no Windows?

Não diretamente. O wcon roda no macOS e no Linux. No Windows, o README indica o WSL.

Quanto o jsonW economiza em relação ao SQLite?

O README não publica essa comparação. Os números publicados, de 4,9 vezes menos espaço e 3.281 vezes mais velocidade na leitura de um campo, são contra JSONL. Para saber o efeito no seu volume, rode wjsw medir na sua máquina.

Preciso escrever o esquema à mão?

Não. O wcon tira o esquema do próprio banco. Para arquivos JSON ou JSONL, o wjsw de-json infere o esquema.

Fontes

• README do jsonW, no repositório developer-wortic/jsonw
• AGENTS.md do jsonW, com as regras para agentes de código
• jsonw.org
• Datatypes In SQLite, documentação oficial do SQLite
• Under the hood, off the hot path: how D1 scales to millions of databases, Cloudflare, 13/10/2026
• Cloudflare Scales D1 Control Plane to Millions of Databases, InfoQ, novembro de 2026

Para conhecer o formato, veja jsonw.org e o repositório no GitHub.

Perguntas frequentes

Dá para tirar dados de um SQLite e devolver sem perder o tipo?

Sim, com o wcon. A ida gera um arquivo .jsw e a volta grava de novo na tabela. Segundo o README do jsonW, a ida e a volta não perdem dados. Antes de voltar, rode o conferir para validar o arquivo.

Por que uma coluna do SQLite pode misturar texto e número?

Porque o tipo pertence ao valor, e a coluna apenas recomenda um tipo. Pela documentação do SQLite, qualquer coluna, exceto a chave inteira primária, aceita valores de classes diferentes.

O jsonW substitui o SQLite?

Não. O jsonW não pede que você troque de banco. Ele leva os dados para um arquivo e devolve ao banco, e o SQLite continua sendo o banco da aplicação.

O zero à esquerda de um CPF se perde na volta?

No jsonW, o tipo codigo guarda os bytes exatos, e o AGENTS.md indica o CPF como caso desse tipo. A perda costuma começar antes, na afinidade do SQLite: um CPF com zero à esquerda, gravado como número numa coluna INTEGER ou NUMERIC, pode perder o zero. Por isso, o caminho mais seguro é declarar essa coluna como texto.

Funciona no Windows?

Não diretamente. O wcon roda no macOS e no Linux. No Windows, o README indica o WSL.

Quanto o jsonW economiza em relação ao SQLite?

O README não publica essa comparação. Os números publicados, de 4,9 vezes menos espaço e 3.281 vezes mais velocidade na leitura de um campo, são contra JSONL. Para saber o efeito no seu volume, rode wjsw medir na sua máquina.

Preciso escrever o esquema à mão?

Não. O wcon tira o esquema do próprio banco. Para arquivos JSON ou JSONL, o wjsw de-json infere o esquema.

Fontes

• README do jsonW, repositório developer-wortic/jsonw
• AGENTS.md do jsonW
• jsonW · json Wondrous
• Datatypes In SQLite, documentação oficial
• Under the hood, off the hot path: how D1 scales to millions of databases (Cloudflare, 13/10/2026)
• Cloudflare Scales D1 Control Plane to Millions of Databases (InfoQ, novembro de 2026)

Conheça: jsonW com SQLite.