Resolver o HTTP não é resolver o banco de dados.

API para Banco de Dados: quanto cada solução entrega pronta

A tabela de comparação a seguir considera especificamente o cenário de APIs orientadas a banco de dados: concorrência, conexões, execução SQL, resiliência, monitoramento e operação.

Java Virtual Threads e AWS Lambda são plataformas de propósito geral. O CrudSqlBuilder é especializado nesse cenário — a comparação mostra quanto cada abordagem já entrega pronto.

APIs geradas a partir do banco: onde as soluções se diferenciam

Supabase, Hasura e PostgREST partem de uma proposta semelhante à do CrudSqlBuilder: transformar os metadados de um banco de dados em uma API REST, sem precisar construir — ou contratar — o servidor do zero. A comparação abaixo destaca onde cada abordagem se diferencia — especialmente em bancos suportados, lógica de negócio e infraestrutura.

Testes de performance

Cada cartão mostra as requisições processadas, a vazão (req/s) e o percentual de erro (timeout de proteção). O ambiente e os critérios do teste estão na Metodologia, mais abaixo.

Qual é o ganho real de uso, com várias conexões ao pool, ou com uma única conexão ao pool?

Em vez de medir só "requisições por segundo" num cenário ideal, testamos o pior caso: 2000 requisições HTTP simultâneas contra o mesmo endpoint durante 1 minuto, variando apenas o tamanho do pool de conexões com o banco SQLite — de 30 conexões até o extremo de uma única conexão disputada por todas as 2000 chamadas ao mesmo tempo.

Nota: os resultados apresentados abaixo foram obtidos sem o uso de cache no endpoint testado. Com o cache de resultados ativado (TTL de 10 segundos), o mesmo teste, com 2.000 requisições simultâneas durante 1 minuto e utilizando um pool de 30 conexões, processou 145.000 requisições em 1 minuto, demonstrando o impacto positivo do cache no desempenho da API. Endpoint usado no teste com cache: /SampleStore/api/Simulator_mix/Mix/Listar_embalagens_cache_10?ID_EMPRESA=1.

Backpressure de verdade, não crash sob pressão: o timeout é uma proteção deliberada, não uma falha — acima de um certo volume de chamadas simultâneas disputando poucas conexões, a aplicação prefere devolver erro controlado pra uma fração das chamadas a deixar a fila crescer sem limite e derrubar o servidor inteiro.

Metodologia usada nos testes de performance

Transparência sobre como esses números foram gerados — vamos manter esta seção sempre atualizada conforme novas rodadas de teste forem publicadas.

• Ferramenta de carga: Apache JMeter, 2000 threads simultâneas por rodada, HTTP KeepAlive habilitado — chamada externa a um servidor dedicado, nunca local.
• Servidor: VM em servidor dedicado no Datacenter Eveo, Windows Server 2025 Standard, CPU Intel Xeon E5-2673 v4 @ 2.30GHz com 12 vCPUs, 12 GB de RAM, disco SSD NVMe.
• Base e API de teste: os testes publicados usam a base de teste e a API de exemplo que acompanham o instalador do servidor, o que permite que a equipe interna de qualquer empresa reproduza o mesmo cenário e compare os resultados no próprio ambiente.
• Banco de dados: SQLite — escolhido por não depender da instalação de um sistema gerenciador de banco de dados (SGBD).
• Variável testada: tamanho do pool de conexões do CrudSqlBuilder (1 / 3 / 10 / 30), mesma janela de 1 minuto em cada rodada.
• Endpoint testado: /SampleStore/api/Simulator_mix/Mix/Listar_embalagens?ID_EMPRESA=1, na base de teste SQLite.
• Consulta de teste: tabela com 10 registros, filtro retornando 4 — o teste isola o custo de admissão e do pool de conexões, não throughput de consulta em grande volume de dados.
• Critério de sucesso: ausência de falhas de servidor ou conexão; chamadas que excedem o timeout de proteção são contabilizadas separadamente.

Requisitos de equipamento recomendados

Pra um uso mais leve — como publicar uma única API com tráfego baixo — o servidor roda tranquilamente até num computador mais simples. Se for realizar seus próprios testes de performance, separe o servidor da máquina que faz as chamadas (o cliente de carga): rodar os dois no mesmo equipamento interfere no resultado, porque a concorrência de quem chama disputa recursos com quem recebe e processa a chamada, prejudicando a análise.