Harper lançou a versão 5.2 com resultados de benchmark comparando sua arquitetura mono-stack contra a stack de quatro componentes do Vercel (Vercel Functions + Neon Postgres + Upstash Redis + Ably). O benchmark publicado predadeja a versão 5.2, mas mostra Harper até 14x mais rápido em caminhos de dados personalizados. A versão 5.2 adiciona cache de registro por worker, agendamento isolado de commits e um novo planejador de queries SQL, testado em 474 testes de carga em oito cenários em duas regiões dos EUA.
No teste, um catálogo de produtos foi construído duas vezes sobre o mesmo contrato de dados: uma vez no Harper (dados, computação, cache e mensagens em um único processo), uma vez nos componentes do Vercel. Uma leitura in-process única custa aproximadamente 0,4ms; um salto de rede para um nível separado custa aproximadamente 3ms. Em cenários de dados em tempo real—leituras simples, valores injetados ao vivo, streaming server-side, frescor write-to-read, fan-out de leitura com carga normal—Harper registrou até 14x mais throughput.
O benchmark tem limitações. Sob carga de fan-out alta e sustentada, o autoscaling serverless do Vercel supera o nó livre único do Harper. O Vercel vence em conteúdo estático armazenável em cache via CDN e real-time broadcast-only. O teste usou um dataset aquecido, em memória; a vantagem in-process diminui quando o working set excede a RAM disponível.
A versão 5.2 apunta para o limite de throughput. Em versões anteriores, commits de banco de dados compartilhavam o pool de workers libuv do Node com todos os outros trabalhos assíncronos, então escritas pesadas privavam operações não relacionadas. Harper isolou cada banco de dados para seu próprio caminho de commit. Durante escritas pesadas, a latência mediana de trabalhos assíncronos não relacionados caiu de 15,1ms para 0,12ms; p99 caiu de 223,7ms para 2,6ms—uma redução de 86x. Pior cenário p99 em um banco de dados sob tensão de 46 GB caiu de 51ms para 3,4ms. O throughput bruto de commit permanece inalterado; o ganho é isolamento, não velocidade.
O cache de registro por worker usa slots de versão atômicos sem lock para servir leituras repetidas sem acessar a camada de armazenamento quando a versão em cache está atual. Leituras aquecidas foram 5–8x mais rápidas; leituras transacionais 5x mais rápidas; busca vetorial 2,6x mais rápida. Leituras frias são inalteradas. O novo planejador de queries SQL roteia queries suportadas diretamente contra os índices do Harper em vez de através de uma camada de execução genérica. Recuperar dez registros pela chave primária de uma tabela com 40.000 linhas caiu de 133,6ms para 1,65ms. Todas as 16 formas de query suportadas no benchmark foram concluídas mais rapidamente com resultados idênticos verificados antes do timing.
Agendamento, backup, roteamento, filtragem de solicitações, segredos criptografados e orquestração de agentes podem ser executados dentro do runtime Harper em vez de como integrações separadas. Menos integrações significam menos credenciais, modos de falha e ciclos de atualização. Como Harper afirmou: "Reduzir limites arquiteturais não é uma preferência estética. Significa menos lugares para latência se acumular, menos contratos para manter sincronizados e menos sistemas para investigar quando algo quebra às 2 da manhã."
O núcleo do Harper é Apache 2.0; Harper Pro adiciona replicação multi-node, gerenciamento de certificados e profiling estendido sob a Elastic License 2.0.