- A Turso conectou um frontend compatível com Postgres ao seu core de banco de dados em Rust, expandindo-o para uma estrutura de LLVM dos bancos de dados, em que um único mecanismo de execução processa várias linguagens de banco de dados
- O SQL do Postgres é analisado em uma AST comum e compilado para bytecode VDBE; o pgmicro, que validou essa possibilidade, foi incorporado à árvore principal de código como base oficial de desenvolvimento
- O core existente oferece compatibilidade com arquivos SQLite, escritas concorrentes com MVCC, execução assíncrona, um sistema de tipos rico e views materializadas com atualização automática, com a confiabilidade verificada por várias técnicas de teste
- Foi projetado para rodar de forma embarcada ou em arquivo único em navegadores, dispositivos móveis e diversos dispositivos, ao mesmo tempo permitindo que aplicações existentes, ORMs e
psqlse conectem pelo protocolo wire do Postgres - Em vez de buscar compatibilidade 100%, o foco é executar a maioria das aplicações existentes sem modificações por meio dos recursos essenciais mais usados; para extensões e PL/pgSQL, são avaliados o uso de WASM e camadas de compatibilidade, com desenvolvimento sob licença MIT
Por que construir o Postgres sobre a Turso
- Turso é um core moderno de banco de dados escrito em Rust, sobre o qual está sendo construído do zero um banco de dados compatível com Postgres
- O objetivo de longo prazo não é simplesmente portar o Postgres existente para Rust, mas criar um novo banco de dados com uma arquitetura moderna
- Não usa um processo separado para cada conexão
- Pode rodar de forma embarcada dentro do navegador
- Permite tratar um banco de dados como um único arquivo
- Views materializadas são atualizadas automaticamente, sem trabalho adicional
- A meta é uma estrutura de compilação com componentes substituíveis, conectando vários frontends a um único core estável
- SQLite é o primeiro frontend
- Postgres é o próximo frontend oficial
- No futuro, também poderão ser adicionados frontends como MySQL, Redis e bancos de dados experimentais
- O resultado atual não é um produto finalizado, mas uma base de desenvolvimento que já pode ser executada na prática
Da reimplementação do SQLite a um core comum de banco de dados
- A Turso começou como um projeto de reimplementação completa do SQLite em Rust e com uma arquitetura moderna, mantendo compatibilidade de arquivos para abrir e criar arquivos SQLite
- Ela já conta com recursos que vão além do escopo do SQLite
- Suporta escritas concorrentes usando MVCC, como o Postgres
- Oferece um sistema de tipos rico, semelhante ao do Postgres
- Opera de forma totalmente assíncrona, adequada para execução nativa mesmo em ambientes restritos como navegadores
- Views materializadas são atualizadas automaticamente em tempo real, dispensando cron jobs de
REFRESH MATERIALIZED VIEWou combinações de triggers
- A adição do frontend Postgres não altera os objetivos existentes da Turso e do SQLite
- A busca por compatibilidade total com SQLite e por expansão de recursos para cargas de trabalho futuras continua
- Ao implementar recursos necessários, também será possível aproveitar testes do Postgres, acelerando o desenvolvimento
Confiabilidade e modelo de contribuição aberto
- Para reproduzir a robustez do SQLite, a confiabilidade é tratada como um recurso do produto
- Usa testes de simulação determinística
- Realiza testes com Antithesis
- Também aplica testes Oracle, fuzzing e métodos formais
- A Turso tem atualmente mais de 260 contribuidores e opera em um modelo de contribuição aberta (Open Contribution), no qual pessoas externas também podem participar da direção do projeto
- A ideia é manter um ambiente no estilo do kernel Linux, centrado no código e em altos padrões de qualidade, onde contribuidores que trabalham continuamente no projeto também participam das decisões
- Contribuições escritas por IA também são aceitas, mas precisam ter qualidade suficiente; pessoas devem revisar o código cuidadosamente e entender a arquitetura
A máquina virtual VDBE dentro do SQLite
- O SQLite não é uma única camada que executa SQL diretamente; ele tem uma estrutura de máquina virtual que compila o SQL do dialeto SQLite para bytecode VDBE e o executa
- VDBE não é um bytecode de uso geral como JVM, .NET ou WASM, mas oferece operações de alto nível específicas de banco de dados, como
encontrar um item em uma B-tree - Essa linguagem de bytecode não tem uma especificação pública nem uma interface modular, mas existe de fato dentro do SQLite, e a Turso adota o mesmo desenho
- Para validar a generalidade do VDBE da Turso, Doom foi convertido com um pequeno compilador de C para VDBE
- O mecanismo real da Turso foi compilado para WASM para executar o bytecode VDBE do Doom em uma aba do navegador
- Doom é executado da mesma forma que o banco de dados processa um
SELECT - Cada frame é tratado como uma linha de resultado
- A área de memória é representada como um blob que pode ser lido e escrito
- A implementação pode ser conferida no repositório turso-vdbe-doom-example
Estrutura de compilação do frontend Postgres
- Tentativas anteriores de combinar SQLite e Postgres dependeram principalmente de tradução na camada de consultas, convertendo consultas Postgres em consultas SQLite, por causa da estrutura monolítica do SQLite; as diferenças de comportamento externo entre os dois bancos geravam um grande descompasso de impedância
- Internamente, a maioria dos bancos de dados SQL executa operações básicas semelhantes, centradas em B-trees e conjuntos de índices
- Há diferenças claras nas estruturas de armazenamento do Postgres e do SQLite
- O Postgres mantém linhas em arquivos heap e usa índices B-tree separados, versões de tuplas, TIDs e vacuum
- O SQLite organiza os dados em B-trees de forma clusterizada
- Essas diferenças surgem principalmente da forma como os bytes são dispostos em disco, e as operações necessárias ao Postgres podem ser representadas pelo VDBE existente ou suportadas por extensões aos comandos VDBE
- Na nova estrutura, é possível trocar o frontend do banco de dados
- A linguagem Postgres é analisada em uma AST comum
- A AST é compilada para bytecode da Turso
- O core comum da Turso executa o bytecode
- O experimento inicial que validou a possibilidade foi feito com pgmicro, e seus resultados foram incorporados à árvore principal de código da Turso, transformando-o em um projeto oficial
Formas de execução e cenários de uso
- O objetivo é oferecer o mesmo SQL e comportamento de banco de dados do Postgres em várias formas, sem servidor
- Rodar um banco de dados realmente compatível com Postgres em uma aba do navegador
- Permitir que agentes criem um novo banco de dados para cada usuário e gerenciem cada um como um único arquivo
- Aplicações local-first baixam dados Postgres em um único arquivo e depois sincronizam novamente
- Rodar de forma embarcada como o SQLite em celulares e diversos dispositivos
- Também há planos de suportar na Turso/Postgres o recurso de sincronizar bancos de dados Turso existentes para arquivos locais
- Além da execução em arquivo único e embarcada, o projeto também inclui protocolo wire e implementação de servidor, para que aplicações existentes, ORMs e
psqlpossam se conectar - No curto prazo, os frontends oficiais desenvolvidos diretamente pela equipe da Turso serão SQLite e Postgres, e a estrutura será aberta para que contribuidores externos possam criar outros frontends
Como executar agora e participar
- Ainda não há um pacote distribuído, mas é possível compilar e executar diretamente a partir do código-fonte
cd postgres/cli && cargo run - O frontend Postgres não é um repositório separado; ele é desenvolvido desde o primeiro dia como frontend oficial dentro da árvore de código da Turso
- O desenvolvimento e as contribuições acontecem no repositório da Turso no GitHub
Objetivos e limites da compatibilidade
- Devido à natureza muito mais complexa do Postgres em comparação com o SQLite, compatibilidade 100% não é tratada como objetivo obrigatório
- O foco é oferecer suporte suficiente aos recursos centrais e amplamente usados para que a maioria dos usuários consiga executar suas aplicações sem modificações
- Quando recursos modernos e compatibilidade perfeita 1:1 entrarem em conflito, a decisão será tomada recurso a recurso
- As views materializadas da Turso usam atualização automática em tempo real
- Ainda não foi decidido se a abordagem tradicional sem atualização automática será implementada separadamente apenas por compatibilidade total
- À medida que o escopo de recursos crescer, a Turso/Postgres poderá se aproximar mais de um banco de dados próprio do que de uma cópia do Postgres
Uso de IA e velocidade de desenvolvimento
- Ferramentas de IA são usadas ativamente, mas revisão de código e entendimento da arquitetura não são dispensados
- Em componentes críticos como bancos de dados, avalia-se que ferramentas de IA ainda não chegaram ao ponto de substituir a responsabilidade pela verificação
- A velocidade por commit pode ser menor do que em um modelo de rodar Fable 24 horas por dia, mas o ponto de partida é um core de banco de dados que já funciona e foi amplamente testado
- Em vez de mudar rapidamente e quebrar o sistema, a opção é implementar corretamente, mesmo que mais devagar
- Concluir todos os recursos exigirá tempo, e alguns passarão por um longo processo de desenvolvimento até que a arquitetura adequada esteja estabelecida
PL/pgSQL e extensões
- PL/pgSQL é uma linguagem procedural, não algo impossível de implementar, mas é mais provável que seja oferecida uma linguagem procedural separada com uma camada de compatibilidade do que uma reimplementação direta
- Foi obtida uma prova de conceito para carregar algumas extensões do Postgres em contêineres WASM
- Extensões que usam apenas símbolos fornecidos pelo contêiner WASM podem ser carregadas arbitrariamente
- Há perda de desempenho decorrente da execução em WASM
- Essa abordagem ainda não foi definida como desenho final
- Um sistema de extensões que permita executar código arbitrário sem restrições é considerado indesejável
- Algumas extensões podem não ser suportadas, mas acredita-se que muitas poderão ser carregadas se forem compiladas para WASM
Cronograma estimado e estratégia open source
- Em vez de criar um banco de dados novo do zero, o projeto parte de um core que já funciona, foi testado e compartilha boa parte da estrutura interna com o Postgres
- Implementar todos os recursos do Postgres pode levar muito tempo, mas espera-se oferecer em alguns meses um subconjunto grande o suficiente de recursos úteis na prática
- Os dois principais desenvolvedores têm atualmente cerca de 44 anos e ainda podem desenvolver por pelo menos mais 20 anos, portanto não há pressa para completar todos os recursos
- A velocidade e o escopo reais do desenvolvimento dependerão fortemente das contribuições da comunidade
- Quando foi implementado suporte multiprocesso para o dialeto SQLite, a equipe não tinha máquinas Windows e deixou a implementação para Windows de fora
- Um desenvolvedor externo que usava muito a Turso se interessou e concluiu o suporte a Windows em uma semana
- Frontends experimentais podem ser desenvolvidos fora da árvore de código, mas o frontend oficial Postgres usará a mesma licença MIT da Turso existente
1 comentários
Comentários no Lobste.rs
Acho que quase todos os bancos de dados SQL compilam consultas para uma máquina virtual (VM)
Nesse sentido, parece um pouco estranho destacar apenas o SQLite
Já o SQLite compila consultas para um bytecode imperativo com variáveis e loops
Como desenvolvedor do pgwire, fico feliz em ver a Turso reutilizando o pgwire em um banco de dados compatível com PostgreSQL
Fico curioso para saber por que a empresa concluiu que precisava de uma mudança de direção
Fico curioso se eles terminaram a reimplementação do SQLite ou se desistiram dela
https://lobste.rs/s/rxdnnq/introducing_first_alpha_turso_next
Parece que eles ainda mantêm esse objetivo, acrescentando também outros front-ends no meio do caminho
É um texto muito interessante, e é uma vergonha que tenha sido denunciado injustamente
De forma alguma é “off-topic” ou “spam”, e não entendo de jeito nenhum por que denunciaram assim
Talvez tenham presumido que era lixo de IA só porque o texto tinha um travessão; parece que as pessoas estão realmente perdendo a cabeça
A cultura de denúncias neste site ficou horrível, então espero que a moderação tome alguma providência. Se bloquearem algumas pessoas que denunciam de má-fé, talvez o restante se contenha
Há tempos eu demonstrava rejeição à postura da Turso de se apresentar como sucessora do SQLite, e por isso prometi a mim mesmo, há alguns anos, que nem sequer testaria o software
Mas, se oferecerem views materializadas com atualização automática rápidas e baratas também fora do SQL Server, talvez eu acabe usando