# De PostgreSQL a SQLite

O projeto nasceu em SQLite, passou para PostgreSQL, e voltou. As duas trocas foram medidas
antes de acontecer, e esta página registra o que cada uma custou — inclusive onde a
recomendação foi ignorada, e por quê isso está certo.

## A pergunta que abriu a volta

> *"Em termos de portabilidade e funcionamento fácil e imediato, totalmente dockerizado,
> vale mais a pena usarmos o SQLite?"*

A resposta exigiu contar as construções específicas do PostgreSQL no código. O primeiro
instrumento deu **87** — e estava sujo: `FILTER (` casava com `.filter(` do Java, e `now()`
com `Instant.now()`. Medindo **só dentro de SQL**, deram 35. E separando honestamente:

| | quantas |
|---|---|
| o SQLite **moderno faz** — tradução mecânica | 20 |
| o SQLite **não faz** — exige repensar | 15 |

`FILTER (WHERE)` existe desde a 3.30; `ON CONFLICT DO UPDATE` desde a 3.24; `RETURNING`
desde a 3.35. `LEAST`/`GREATEST` viram `MIN`/`MAX` com vários argumentos. `date_trunc` e
`EXTRACT` viram `substr` da string ISO.

Sobraram três: `TIMESTAMPTZ` (11 usos), `AT TIME ZONE` (3) e `xmax = 0` (1).

**E todo o `ILIKE` morava em `cliente` e `contato`** — as fatias que saíram no mesmo
trabalho. Esse custo desapareceu sozinho.

## A recomendação foi outra, e está registrado

A recomendação era **ficar no PostgreSQL** e resolver a dor real por outro caminho — a dor
não era o motor, era o Dev Services perdendo o contêiner (21.542 eventos, duas vezes num
dia). `docker-compose` mais volume nomeado dariam um comando, portabilidade e dado que não
some, sem reescrita alguma.

A decisão foi do Paulo, e foi pelo SQLite. Registrar a divergência importa: quem ler este
código daqui a um ano precisa saber que a troca foi **escolha informada**, não desconhecimento
do custo.

## O que se perdeu, e o que substituiu

**O SQLite não tem tipo de data.** Datas são TEXT, REAL ou INTEGER, e ele aceita qualquer
coisa em qualquer coluna. A disciplina de UTC deste projeto morava no **tipo** da coluna — e
tipo é mecanismo: não depende de ninguém lembrar.

No lugar, três coisas, e as três são do banco:

1. **instante é texto ISO-8601 terminado em `Z`** — `2026-09-03T01:23:45Z`, sempre 20
   caracteres;
2. **`CHECK (coluna LIKE '%Z')` em toda coluna de instante** — gravação em hora local é
   **recusada pelo banco**, não aceita em silêncio;
3. **largura fixa faz a ordem alfabética coincidir com a cronológica** — `ORDER BY`, `MIN` e
   `MAX` continuam corretos sem função de data, e `substr(x,1,4)` é o ano.

O truncamento em segundos não é detalhe: `Instant.toString()` **omite** a fração quando ela é
zero, e a largura variável inverteria a ordem de dois eventos separados por um décimo de
segundo.

## Dois defeitos que a troca produziu, e como apareceram

### A migração aplicou 1 objeto de 9 e disse "aplicada"

O driver do SQLite executa o **primeiro** comando de um script e ignora o resto — **sem
erro**. O log dizia `aplicadas=1`, e o banco tinha uma tabela de nove.

O pior não foi a aplicação parcial: foi a migração ter ficado **marcada como aplicada**. O
segundo arranque não a repetiria, e o banco ficaria pela metade para sempre, com a evidência
disponível afirmando que estava tudo certo.

A correção divide o script sabendo quando o `;` está dentro de literal, de identificador
entre aspas ou de comentário — o comentário anterior avisava que `split(";")` é bomba-relógio,
e estava certo. **A contagem é verificada**: zero comando é defeito, não migração vazia.

### A detecção de inseriu-vs-atualizou errava dentro do mesmo segundo

O `xmax = 0` do PostgreSQL não tem equivalente. A primeira substituição comparava
`criado_em = sincronizado_em` — e o instante trunca em segundos, então duas sincronizações no
mesmo segundo gravavam o mesmo texto e a comparação dizia "inseriu".

**O teste de idempotência pegou na primeira execução.** Virou um contador `versao`, que não
depende de resolução de relógio nenhuma — e de quebra responde algo que ninguém sabia:
quantas vezes a NASA republicou cada evento.

## O que ficou provado, rodando

```
CEP 01310100 ........ -23,5617698  -46,6553299   (Avenida Paulista)
instante gravado .... 2026-09-03T12:11:40Z
e-mail repetido ..... "você já está inscrito", 200, uma linha só
sincronizar 2023 .... 271 trazidos · 271 novos · 0 atualizados
a MESMA de novo ..... 271 trazidos · 0 novos · 271 atualizados
duplicatas .......... 0
instantes fora do formato ... 0
```

## O que continua valendo da primeira troca

O defeito que motivou a passagem original para PostgreSQL — `SQLITE_CANTOPEN` no arranque —
**não era do SQLite**. Foi medido na época: zero dos três defeitos daquele dia eram do motor.
A causa era o SQLite criar o **arquivo** e nunca a **pasta**, e a correção
(`PreparadorDoArquivoSqlite`) voltou junto com ele.