Perplexity ha sacado Amazon DynamoDB de la ruta de lectura que sirve el contenido web de su producto de búsqueda y lo ha reemplazado por CobbleDB, un almacén clave-valor propio de unas 40.000 líneas de Rust. Dos ingenieros lo construyeron en cerca de dos meses mientras dirigían a cientos de agentes de programación persistentes y siempre activos, según la investigación sobre CobbleDB publicada por la compañía. A ninguno de esos agentes se le permitió autorizar un despliegue en producción.
Claves del caso
- La latencia mediana de lectura por lotes bajó de 31,4 ms en DynamoDB a 5,60 ms en CobbleDB, una mejora cercana al 82 %, mientras que la latencia en el percentil 99 cayó de 123 ms a 24,2 ms.
- Dos ingenieros dirigieron a cientos de agentes de programación durante unos dos meses y se reservaron las decisiones de arquitectura, la revisión de código y la autorización de producción.
- El consejero delegado de Perplexity, Aravind Srinivas, afirmó que abandonar DynamoDB puede ahorrar a la empresa hasta 100 millones de dólares al año; las proyecciones internas sitúan el coste de la capa de almacenamiento más de un 20 % por debajo de DynamoDB a gran escala.
Por qué Perplexity se alejó de DynamoDB
El detonante fue una mezcla de precio y control. Perplexity concluyó que pagaba de más por DynamoDB y aun así no obtenía el margen de ajuste que quería sobre el rendimiento de lectura, una restricción que pesa cuando cada respuesta que genera el producto depende de recuperar muchos documentos almacenados a la vez.
DynamoDB cobra en buena medida por bytes movidos, un modelo que encaja mejor con cargas transaccionales que con los patrones amplios y dominados por la lectura de un motor de respuestas. El argumento de Perplexity es que un almacén hecho a medida de su propia forma de acceso podía superar a un servicio gestionado de propósito general en los dos ejes a la vez.
Cómo está montado el sistema
En lugar de levantar un monolito, Perplexity dividió el trabajo en tres componentes que se ajustan por separado. Pillar gestiona la durabilidad de los documentos y rastrea versiones a medida que cambian los registros. Lorry agrupa las actualizaciones entrantes en lotes y las introduce en el sistema. CobbleDB se sitúa en la capa de servicio, dedicada por completo a lecturas de baja latencia en el momento de la consulta.
Por debajo, CobbleDB se apoya en RocksDB para las transacciones de datos propiamente dichas. Sobre esos cimientos el equipo añadió estrategias ajustables de particionado y caché pensadas para sostener el rendimiento en picos de carga. Las cifras publicadas muestran que la mejora fue consistente en toda la distribución y no solo en la mediana: la latencia del percentil 90 pasó de 56,7 ms a 9,77 ms.
Qué podían y qué no podían hacer los agentes
El reparto de trabajo es la parte que el sector va a discutir. Perplexity describió el desarrollo como dos ingenieros más cientos de agentes de IA proactivos y siempre activos que aportaron inspección continua y seguimiento entre sesiones. Srinivas resumió el resultado en X como un sustituto de DynamoDB construido por dos ingenieros y cientos de agentes persistentes en dos meses. Los humanos conservaron las decisiones con mayor radio de impacto.
Ese reparto es una línea de gobernanza deliberada, no una limitación técnica. Los agentes generaban y revisaban código; los ingenieros eran dueños de la arquitectura, revisaban lo que entraba y mantenían la potestad de poner cualquier cosa frente a tráfico real. Escribir infraestructura y operar infraestructura se trataron como privilegios distintos.
Cómo se compara con la reescritura en Rust de OpenAI
La forma resultará familiar. Días antes, OpenAI contó que dos ingenieros y Codex reescribieron en Rust el servicio que sostiene cada lectura de datos de ChatGPT. Que dos laboratorios lleguen por separado al mismo patrón — un equipo humano mínimo, una flota grande de agentes, Rust y una ruta caliente de almacenamiento — sugiere que el patrón se está convirtiendo en plantilla y no en una excepción.
A qué renunció Perplexity
CobbleDB no es un clon funcional de DynamoDB. No admite consistencia fuerte ni transacciones complejas, dos cosas que un servicio gestionado ofrece por defecto. Es un intercambio asumible para servir documentos web cacheados a un índice de búsqueda, y descalificante para sistemas que necesitan garantías transaccionales.
Perplexity se ha comprometido a liberar CobbleDB como código abierto una vez que el sistema demuestre validación en producción a escalas de cientos de miles de peticiones por segundo, aunque no ha fijado fecha. Hasta que el código sea público, las cifras de latencia y coste descansan en las mediciones de la propia empresa.
Preguntas frecuentes
¿CobbleDB es de código abierto?
Todavía no. Perplexity ha dicho que pretende liberarlo después de que el sistema se demuestre en producción a escalas de cientos de miles de peticiones por segundo. No se ha anunciado una fecha de publicación.
¿CobbleDB sustituye a DynamoDB por completo?
Sustituye la capa de lectura del contenido web en la pila de búsqueda de Perplexity, no todos los usos de DynamoDB. CobbleDB carece de consistencia fuerte y de soporte para transacciones complejas, así que las cargas que necesiten esas garantías no son candidatas.
¿Cuánto código escribieron realmente los agentes de IA?
Perplexity no ha publicado un desglose línea a línea de las aproximadamente 40.000 líneas de Rust. La compañía atribuye a cientos de agentes de programación persistentes el grueso de la implementación a lo largo de dos meses, con dos ingenieros a cargo de la arquitectura, la revisión y la autoridad de despliegue.
