SQLx vs Diesel vs SeaORM para um back-end Rust rápido

SQLx, Diesel e SeaORM não são três variações da mesma ferramenta. SQLx é um kit de ferramentas de baixo nível — um driver Postgres aumentado com uma verificação opcional. Diesel é um ORM clássico no sentido Rust: uma camada de tipos acima do SQL. SeaORM é um ORM no sentido Ruby/Python: entidades, relacionamentos, carregamento de objetos. A tabela abaixo apresenta os fatos verificáveis, todos datados de 23 de agosto de 2026.

Versões, downloads e estrelas: API crates.io e API GitHub, consultados em 23 de agosto de 2026. Repositório SQLx rastreado em transact-rs/sqlx (anteriormente launchbadge/sqlx).

Downloads dos últimos 90 dias, em milhões (camporecent_downloads da API crates.io). Fonte: crates.io, entrevista em 23 de agosto de 2026.

SQLx se descreve como "uma caixa Rust SQL assíncrona e pura com consultas verificadas em tempo de compilação sem DSL" (README oficial, github.com/transact-rs/sqlx, acessado em 23 de agosto de 2026). Sem construtor de consultas, sem entidades: você escreve SQL e o SQLx oferece duas maneiras de executá-lo.

// Modo 1 — macro em tempo de compilação: verificado em um banco de dados de desenvolvimento real
let user = sqlx::query_as!(User, "SELECT id, email FROM users WHERE id = $1", user_id)
    .fetch_one(&pool)
    .await?;

// Modo 2 — dinâmico: tabelas/colunas decididas em tempo de execução
let sql = format!("SELECT * FROM {table} WHERE id = $1");
let row = sqlx::query(&sql).bind(user_id).fetch_one(&pool).await?;

O modo 1 requer um banco de dados acessível no momento de cargo build — a macro se conecta a ele para verificar os tipos. O Modo 2 não possui verificações estáticas, mas aceita qualquer string SQL construída em tempo de execução — incluindo nomes de tabelas. Este é o modo que o Aurabase utiliza (seção 06).

Objeção comum contra o modo 1: como construir em CI sem uma base de desenvolvimento acessível? sqlx-cli responde em modo offline (documento oficial sqlx-cli, consultado em 23 de agosto de 2026):

1. Localmente, com um banco de dados de desenvolvimento conectado, inicie cargo sqlx prepare: os metadados de cada solicitação verificada são gravados em uma pasta .sqlx.
2. Envie esta pasta .sqlx para o repositório, próximo ao código.
3. No CI, defina SQLX_OFFLINE=true: a compilação lê os metadados versionados e não tenta mais se conectar a um banco de dados real.

A mesma ferramenta também gerencia migrações (sqlx migrate add / run / revert) — uma função que aura-migrations assume separadamente no lado do Aurabase.

Diesel se apresenta como “um ORM seguro e extensível e construtor de consultas para Rust” (site oficial diesel.rs, acessado em 23 de agosto de 2026). O projeto também afirma que “elimina a possibilidade de interações incorretas com o banco de dados em tempo de compilação”. A diferença básica com o SQLx: o Diesel verifica suas consultas no próprio sistema do tipo Rust, sem precisar de um banco de dados conectado no momento da construção.

A própria página de comparação oficial do Diesel (acessada em 23 de agosto de 2026) localiza a diferença: Diesel “também pode verificar partes da consulta em tempo de compilação”. Isso permite que você crie consultas dinâmicas já verificadas — um IN em um vetor Rust, uma inserção em lote, uma cláusula condicional. SQLx, por outro lado, “sempre precisa saber toda a consulta em tempo de compilação” para sua macro: esses três casos permanecem fora do escopo do modo 1 visto acima.

Diesel é síncrono por padrão; async passa pela caixa separada diesel-async. Esta mesma página relata que a equipe crates.io mediu um ganho de 20% em um de seus endpoints após mudar para o pipeline PostgreSQL do diesel-async. A página indica que esta funcionalidade está faltando no SQLx e no SeaORM. Esta é uma declaração da Diesel em seu próprio site sobre um único ponto final, não uma medição independente que reproduzimos ou generalizamos: deve ser tomada como tal.

Diesel também inclui suas próprias ferramentas de migração e geração de esquema (README oficial, acessado em 23 de agosto de 2026). diesel migration run aplica arquivos SQL versionados. diesel print-schema regenera o módulo Rust schema.rs que descreve suas tabelas - a parte que o restante do construtor de consultas com segurança de tipo consome para verificar suas consultas em tempo de compilação.

SeaORM se descreve como "um ORM assíncrono e dinâmico para Rust" (site oficial sea-ql.org/SeaORM, acessado em 23 de agosto de 2026), com um modelo ActiveModel inspirado em ORMs Ruby/Python/Node. Relacionamentos 1-1, 1-N, M-N e auto-referenciados, carregamento inteligente por join ou por data loader, entidades que podem ser geradas a partir de um banco de dados existente via sea-orm-cli. A verificação é feita em tempo de execução, não na compilação.

Ponto frequentemente esquecido: SeaORM nem sempre é uma alternativa ao SQLx, às vezes tem duas camadas no topo. A geração de SQL passa por sea-query, seu próprio construtor de consultas dinâmicas. É uma dependência não opcional de sea-orm 2.0.2 (descrição do crates.io: “um construtor de consultas dinâmicas para MySQL, Postgres e SQLite”, verificado em 23 de agosto de 2026). A execução passa por sqlx/sqlx-core e sea-query-sqlx — três dependências declaradas opcionais, ativadas por recurso (sqlx-postgres, etc. — API crates.io, verificada em 23 de agosto de 2026). Concretamente: escolher o SeaORM com o backend Postgres padrão significa adicionar um construtor de consultas e depois entidades/relações sobre o SQLx, não substituí-lo.

As migrações seguem a mesma lógica de ferramentas dedicadas: sea-orm-cli migrate generate/up/down gerencia o controle de versão do esquema. sea-orm-cli generate entity então regenera os arquivos de entidade do banco de dados atualizado - uma viagem de ida e volta do esquema para código mais próxima de diesel print-schema do que do modo dinâmico do SQLx.

Escolha SQLx se…

• Esquema decidido na execução (multilocatário, introspecção dinâmica)
• Você quer ficar perto do SQL, sem DSL para aprender
• Assíncrono nativo não negociável

Escolha Diesel se…

• Esquema estável, conhecido na construção
• Verificação estática enviada sem banco de dados conectado ao tempo de compilação
• Sincronização padrão aceitável ou diesel-assíncrono para pipeline

Escolha SeaORM se…

• Ergonomia do ActiveRecord: relacionamentos, gráficos de objetos
• Entidades geradas a partir de um banco de dados existente
• Mais uma camada de abstração acima de um driver SQL não é problema

O espaço de trabalho Aurabase Cargo fixa sqlx = "0.8" com os recursos postgres, runtime-tokio-rustls, uuid, chrono, json, derive e rust_decimal. Os serviços aura-db e aura-db-adapters dependem diretamente dele (verificado no repositório Cargo.toml, 23 de agosto de 2026).

O que importa mais do que uma linha de dependência: nenhuma chamada para a macro sqlx::query! ou query_as! neste código (0 ocorrências), em comparação com 532 chamadas para sqlx::query()/query_as(), a forma dinâmica. A razão é arquitetônica, não uma preferência de estilo. Cada projeto Aurabase reside em seu próprio esquema Postgres, resolvido no login por SET LOCAL search_path. O nome da tabela consultada chega na solicitação HTTP, não no binário compilado.

O pool de conexões em si permanece SQLx padrão: libs/aura-db-adapters abre seu pool via PgPoolOptions::new() (verificado em postgres/mod.rs, 23 de agosto de 2026), sem sobreposição proprietária neste nível. O que é proprietário vem acima: roteamento de locatário, validação de identificadores de tabela injetados em SQL dinâmico e construção de cláusulas WHERE/filtros compatíveis com PostgREST.

// O esquema de destino é resolvido por consulta, não conhecido na compilação
sqlx::query("SET LOCAL search_path TO $1, public")
    .bind(project_schema)
    .execute(&mut *tx).await?;

// Tabela/colunas decididas pela camada REST dinâmica (compatível com PostgREST)
let sql = format!("SELECT * FROM {} WHERE {}", table, where_clause);

O modelo de verificação estática de Diesel assume um padrão conhecido no momento em que o binário é compilado. O oposto: um único binário que serve um número ilimitado de padrões por projeto, descobertos em tempo de execução. A geração de entidade do SeaORM faz a mesma suposição de um esquema fixo. Este não é um veredicto sobre SQLx versus Diesel em termos absolutos — é uma escolha de arquitetura: padrão conhecido na construção versus padrão resolvido em tempo de execução. Para obter detalhes sobre particionamento de esquema por projeto e políticas RLS associadas, consulte nossa Documentação do banco de dados e o guia RLS .

SQLx, Diesel e SeaORM cobrem três necessidades diferentes, não três lugares no mesmo pódio. Diesel verifica um padrão que você conhece antecipadamente o mais cedo possível. SeaORM economiza tempo na usabilidade do objeto se você aceitar mais uma camada de abstração - geralmente sobre o próprio SQLx. O SQLx continua sendo o mais básico dos três: é isso que o torna adequado para um padrão que você só conhece em tempo de execução, como o roteamento multilocatárioaura-db.

Se você estiver migrando um projeto existente para Postgres e procurando o que realmente muda no esquema RLS e nas políticas, nosso guia de migração Supabase → Aurabase detalha o assunto.