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.
Perplexity construyó CobbleDB para una carga de búsqueda concreta
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.
Las cifras de latencia son llamativas, pero proceden de una comparación antes-después
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.
| Métrica | DynamoDB antes de la migración | CobbleDB después de la migración |
| Latencia mediana de lectura por lotes | 31,4 ms | 5,60 ms |
| Percentil 90 de latencia | 56,7 ms | 9,77 ms |
| Percentil 99 de latencia | 123 ms | 24,2 ms |
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.
Pillar, Lorry y CobbleDB separan el trabajo
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.
| Componente | Función | Tecnología relacionada |
| Pillar | Mantiene el estado duradero y versionado de los documentos, incluidos metadatos, fragmentos y embeddings | YTsaurus sobre almacenamiento HDD |
| Lorry | Convierte las exportaciones en lotes alineados con las particiones y los entrega para su ingestión | Amazon S3 como plano de datos |
| CobbleDB | Ingresa los registros preparados y atiende las lecturas de búsqueda | RocksDB, memoria y NVMe local |
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.
Cientos de agentes ayudaron, pero los humanos conservaron el control de producción
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.
El precio de la velocidad es una responsabilidad operativa mayor
CobbleDB utiliza tres réplicas por partición, pero no exige transacciones ni réplicas sincronizadas para la carga de trabajo descrita. El sistema acepta que exista un breve intervalo entre la escritura de un documento y su disponibilidad para las lecturas.
Ese intercambio tiene sentido en una ruta que sirve contenido preparado y prioriza la velocidad de lectura. No ofrece la misma respuesta que una base de datos diseñada para transacciones complejas o para exigir consistencia fuerte en cada operación. La ventaja de CobbleDB depende, precisamente, de que el servicio de búsqueda puede trabajar con esas condiciones.
La otra cara es operativa: Perplexity controla la colocación de particiones, las cachés, el enrutamiento y la selección de réplicas, pero también debe mantener el almacén, gestionar sus fallos y asumir el coste de evolución del software. El ahorro calculado frente a DynamoDB no incluye ese trabajo.
Perplexity planea publicar CobbleDB como código abierto
Perplexity dijo el 14 de septiembre de 2026 que planea publicar CobbleDB como código abierto para que otros equipos que desarrollen sistemas de búsqueda orientados a la IA puedan utilizar una capa de almacenamiento similar.
