Perplexity, una empresa dedicada a la búsqueda y procesamiento de datos, decidió abandonar DynamoDB tras detectar que pagaba precios elevados por un servicio que no le ofrecía el control necesario sobre el rendimiento de lectura. Con esta motivación, y en un intenso proyecto de apenas dos meses, desarrolló internamente su propia base de datos a la que denominaron CobbleDB.
Este almacenamiento clave-valor está construido en Rust y consta aproximadamente de 40.000 líneas de código. Su desarrollo contó con el apoyo de cientos de agentes persistentes de inteligencia artificial que participaron activamente en la codificación y pruebas, aunque nunca tuvieron acceso al entorno de producción.
En producción, CobbleDB ya asume parte del tráfico de búsqueda de Perplexity y los resultados obtenidos en términos de latencia son notables: la latencia media en lecturas por lotes descendió de 31,4 milisegundos con DynamoDB a 5,6 milisegundos tras la migración, es decir, casi cinco veces más rápida. Los picos de latencia, que antes alcanzaban 123 milisegundos, ahora son de 24,2 milisegundos. Además, en pruebas de carga, CobbleDB soportó hasta 500.000 solicitudes por segundo antes de que el rendimiento comenzara a caer. 
En cuanto al coste, se espera que esta solución casera sea al menos un 20 % más barata que DynamoDB según las previsiones, aunque estas evaluaciones no incluyen los gastos asociados al mantenimiento y desarrollo continuo de la base de datos ni la ingeniería involucrada.
Limitaciones con DynamoDB
La capa de servicio de búsqueda de Perplexity requiere acceder a fragmentos previamente divididos de documentos y embeddings vectoriales. Cada llamada al API de búsqueda recupera entre 100 y 120 claves de páginas repartidas en lotes de entre 10 y 20, con un tamaño medio por elemento de unos 50 KB.
DynamoDB ofrecía un control muy limitado sobre la gestión de lecturas, lo que provocaba que una réplica lenta pudiera ralentizar toda la operación. Además, la empresa enfrentaba costes considerables debido al constante volumen de lecturas y escrituras derivadas del rastreo, procesamiento y búsqueda, lo que dificultaba justificar los gastos en servicios en la nube conforme el volumen de datos y el tráfico aumentaban.
Por estos motivos, Perplexity optó por separar el almacenamiento a largo plazo de los documentos —que se mantiene en sistemas de almacenamiento en disco duro como YTsaurus— de la base de datos que atiende las búsquedas en tiempo real, es decir, CobbleDB.
Arquitectura en tres niveles del almacenamiento de búsqueda
El sistema de almacenamiento se desliza en tres niveles: Pillar gestiona el estado duradero de los documentos en YTsaurus sobre discos HDD, almacenando la metainformación versionada, fragmentos y embeddings. Lorry se encarga de agrupar las actualizaciones en lotes específicos para cada partición y los transporta a través de S3 hacia CobbleDB.
Los datos procesados de cada página se distribuyen en tres réplicas por partición, usando URLs hashadas como claves. RocksDB mantiene en memoria los datos más consultados, mientras que el resto permanece en unidades locales NVMe. Las lecturas se intentan ejecutar dentro de la misma zona de disponibilidad y, en caso de encontrarse una réplica lenta, el sistema puede acudir a otra para no bloquear el lote de solicitudes.
Las actualizaciones llegan mediante S3 y se aplican de forma independiente por réplica, así una copia puede retrasarse y ponerse al día sin afectar al resto.
El papel de los agentes de IA en el desarrollo
Los sofisticados agentes de inteligencia artificial mantuvieron el contexto a lo largo de las sesiones, detectando errores en las suposiciones para restaurar y en la configuración en tiempo real, colaborando en la creación de correcciones y en la realización de pruebas. No obstante, los controladores del sistema en producción fueron siempre dos ingenieros humanos que supervisaron la arquitectura y operatividad para minimizar riesgos.
Esta cautela responde a advertencias de expertos como Andy Pavlo, profesor de la Universidad Carnegie Mellon, quien expuso en Percona Live que las bases de datos suponen el mayor reto para los agentes de IA debido a la dificultad de revertir errores que afecten a datos críticos en producción.
Ventajas y retos de una solución propia
Crear y poner en marcha CobbleDB en tan solo ocho semanas permitió a Perplexity superar cuellos de botella tecnológicos inmediatos, pero mantiene el gran desafío de sostener y evolucionar una infraestructura propia a largo plazo. Los resultados de latencia no fueron medidos en un entorno controlado de doble prueba simultánea, y aunque las previsiones de coste económico resulten favorables, hay que considerar los recursos dedicados a mantenimiento y respuesta ante incidencias.
El caso de Perplexity se suma a empresas como Shopify o Ramp, que han desarrollado agentes de código personalizados complementando modelos de terceros. En su contexto, mantener infraestructura propia sigue siendo atractivo y, gracias al desarrollo asistido por IA, esta opción es cada vez más viable para equipos de ingeniería reducidos, cambiando el paradigma tradicional de depender exclusivamente de servicios gestionados en la nube.
