La base de datos distribuida, escrita en Rust con ayuda de cientos de agentes de programación, redujo la latencia de lectura en el servicio descrito por Perplexity, a cambio de asumir más responsabilidad operativa.
Perplexity creó CobbleDB para acelerar búsquedas con IA: latencia, arquitectura, agentes de programación, costes y límites del sistema.
Perplexity presentó el 14 de septiembre de 2026 CobbleDB, un almacén distribuido de clave-valor diseñado para servir, durante las búsquedas con IA, pasajes ya divididos y sus embeddings vectoriales. En la comparación de producción comunicada por la compañía, la latencia mediana de lectura por lotes bajó de 31,4 milisegundos con DynamoDB a 5,60 milisegundos con CobbleDB, mientras que el percentil 99 pasó de 123 a 24,2 milisegundos.
El movimiento no consiste en sustituir DynamoDB en toda Perplexity: CobbleDB ocupa una parte concreta de la arquitectura de servicio de búsqueda. Ahí está la clave de la historia. Perplexity ha construido una pieza muy especializada para una tarea repetitiva y de alta demanda, y a cambio debe operar y mantener su propia base de datos.
CobbleDB no pretende ser una base de datos generalista. Sus claves son identificadores de páginas procesados mediante hash, y sus valores contienen pasajes previamente fragmentados y embeddings vectoriales asociados a cada fragmento. El diseño está pensado para lecturas por lotes repetidas, no para cubrir cualquier tipo de aplicación empresarial.
Una solicitud de la API de búsqueda contiene aproximadamente entre 100 y 120 claves de página, que se dividen en lotes más pequeños. En el escenario de producción descrito, cada elemento ocupa de media unos 50 KB. Esa forma de trabajar permite optimizar el camino de lectura para un patrón muy concreto, en lugar de pagar la flexibilidad y las funciones de un servicio generalista que Perplexity no necesita en este punto de su buscador.
El núcleo de CobbleDB tiene aproximadamente 40.000 líneas de Rust. Utiliza RocksDB como motor integrado de clave-valor, mantiene en memoria los registros almacenados en caché y recurre a unidades NVMe locales para los datos que no están en caché. Cada partición cuenta con tres réplicas distribuidas en tres nodos diferentes.
Perplexity midió el comportamiento de la ruta anterior con DynamoDB y el de la nueva ruta con CobbleDB en momentos distintos de la operación real. No se trata de una prueba simultánea con tráfico idéntico, una diferencia importante al interpretar los resultados.
La reducción mediana calculada a partir de esas cifras es de aproximadamente el 82,2 %. Durante las mediciones de producción, el sistema atendía alrededor de 200.000 solicitudes por segundo. En una prueba de carga posterior, Perplexity comunicó que CobbleDB alcanzó hasta 500.000 solicitudes por segundo antes de que el rendimiento comenzara a degradarse; ese dato corresponde a una prueba de carga, no a tráfico de producción sostenido.
Perplexity también calculó que el coste de la capa de almacenamiento sería al menos un 20 % inferior al de DynamoDB en los niveles de compromiso evaluados. La estimación se refiere al almacenamiento, las lecturas y las escrituras contempladas por su modelo, y no incluye el coste de ingeniería y mantenimiento de una base de datos propia.
La arquitectura divide el recorrido de los documentos en tres piezas. La separación evita que el procesamiento de documentos y la entrega de lecturas tengan que ajustarse a las mismas prioridades.
Pillar decide qué subconjuntos de páginas deben exportarse. Lorry lee esos registros desde una cola persistente alineada con las particiones, crea archivos por partición y los registra para CobbleDB. Las réplicas recuperan y aplican los lotes de forma independiente y en orden cronológico, de modo que una réplica lenta puede ponerse al día sin detener al resto.
En el momento de responder una consulta, un enrutador sin estado transforma las claves en particiones, agrupa las lecturas y las envía en paralelo. CobbleDB prefiere una réplica de la misma zona de disponibilidad y puede consultar otra si una lectura se retrasa. Para recuperar varios elementos utiliza RocksDB MultiGet.
Perplexity desarrolló CobbleDB con dos ingenieros y la asistencia de cientos de agentes de programación persistentes durante aproximadamente dos meses. Los agentes participaron en tareas como inspección del código, detección de riesgos, pruebas, correcciones, documentación y seguimiento del contexto del proyecto.
La arquitectura, la revisión de los cambios importantes y la autorización de las operaciones de producción permanecieron en manos de los ingenieros. Por tanto, CobbleDB no fue construido de forma enteramente autónoma por agentes: el modelo descrito combina automatización intensiva en el trabajo de desarrollo con control humano en las decisiones que afectan al sistema en producción.
