Harper lanzó la versión 5.2 con resultados de benchmark comparando su arquitectura mono-stack contra el stack de cuatro componentes de Vercel (Vercel Functions + Neon Postgres + Upstash Redis + Ably). El benchmark publicado es anterior a la versión 5.2, pero muestra que Harper es hasta 14x más rápido en rutas de datos personalizados. La versión 5.2 añade caché de registro por worker, programación aislada de commits y un nuevo planificador de queries SQL, probado en 474 pruebas de carga en ocho escenarios en dos regiones de EE.UU.
En la prueba, un catálogo de productos se construyó dos veces con el mismo contrato de datos: una vez en Harper (datos, cómputo, caché y mensajería en un único proceso), una vez en los componentes de Vercel. Una lectura in-process única cuesta aproximadamente 0,4ms; un salto de red a un nivel separado cuesta aproximadamente 3ms. En escenarios de datos en tiempo real—lecturas simples, valores inyectados en vivo, streaming del lado del servidor, frescura write-to-read, fan-out de lectura con carga normal—Harper reportó un throughput hasta 14x más rápido.
El benchmark tiene limitaciones. Bajo carga de fan-out alta y sostenida, el autoescalado serverless de Vercel supera al nodo gratuito único de Harper. Vercel gana en contenido estático cacheable vía CDN y real-time broadcast-only. La prueba utilizó un dataset caliente, en memoria; la ventaja in-process se estrecha cuando el working set excede la RAM disponible.
La versión 5.2 apunta al techo de throughput. En versiones anteriores, los commits de base de datos compartían el pool de workers libuv de Node con todo el trabajo asincrónico, por lo que las escrituras pesadas privaban de recursos a operaciones no relacionadas. Harper aisló cada base de datos en su propia ruta de commit. Durante escrituras pesadas, la latencia mediana del trabajo asincrónico no relacionado cayó de 15,1ms a 0,12ms; p99 cayó de 223,7ms a 2,6ms—una reducción de 86x. El peor caso de p99 en una base de datos bajo estrés de 46 GB cayó de 51ms a 3,4ms. El throughput bruto de commit no cambia; la ganancia es aislamiento, no velocidad.
El caché de registro por worker utiliza slots de versión atómicos sin bloqueos para servir lecturas repetidas sin acceder a la capa de almacenamiento cuando la versión en caché es actual. Las lecturas calientes fueron 5–8x más rápidas; lecturas transaccionales 5x más rápidas; búsqueda vectorial 2,6x más rápida. Las lecturas frías no cambian. El nuevo planificador de queries SQL enruta queries soportadas directamente contra los índices de Harper en lugar de a través de una capa de ejecución genérica. Recuperar diez registros por clave primaria de una tabla de 40.000 filas cayó de 133,6ms a 1,65ms. Las 16 formas de query soportadas en el benchmark se completaron más rápidamente con resultados idénticos verificados antes del cronometraje.
Programación, copia de seguridad, enrutamiento, filtrado de solicitudes, secretos cifrados y orquestración de agentes pueden ejecutarse dentro del tiempo de ejecución de Harper en lugar de como integraciones separadas. Menos integraciones significan menos credenciales, modos de fallo y ciclos de actualización. Como Harper declaró: "Reducir los límites arquitectónicos no es una preferencia estética. Significa menos lugares donde la latencia se acumula, menos contratos para mantener sincronizados y menos sistemas que investigar cuando algo se rompe a las 2 de la mañana."
El núcleo de Harper es Apache 2.0; Harper Pro añade replicación multi-node, gestión de certificados y profiling extendido bajo la Elastic License 2.0.