Cada vector database que he usado en los últimos dos años tiene la misma forma: un servidor. Levantás un container, te conectás por la red, serializás tus embeddings, los mandás a través, y esperás. La espera nunca es larga en términos absolutos — 20ms, 50ms, 150ms — pero siempre está, siempre es un hop, siempre es un evento facturable.
La tesis local-first
VantaDB arranca de una premisa diferente: el hop de red más rápido es no tener hop de red. Si tu aplicación necesita retrieval híbrido — BM25 para keywords, HNSW para vectores, RRF para fusionarlos — ese retrieval debería pasar dentro del proceso que ya tiene los embeddings. Sin serialización. Sin pool de conexiones. Sin API key. Sin costo por query.
Esto no es un rechazo de las cloud databases. Pinecone y Weaviate son productos excelentes para equipos que necesitan escala managed, replicación multi-región, y que alguien más cargue con el pager. VantaDB es para los otros casos: agentes que necesitan memoria durable, pipelines RAG que no pueden filtrar datos, dispositivos edge sin acceso a la nube, y developers que quieren shipear sin una tarjeta de crédito registrada.
Por qué Rust, por qué PyO3
Elegimos Rust para el core porque memory safety no es opcional en una base de datos, y porque la performance determinista no es opcional en un motor de retrieval. No hay pausa de garbage collector que explicar en un chart de p99 latency. Los bindings PyO3 exponen un boundary estable de src/sdk.rs — los callers de Python nunca tocan raw pointers, y la superficie del FFI es lo suficientemente angosta para auditarla a mano.
El resultado es un motor que corre in-process, sirve queries híbridas en 1.2ms, se recupera de crashes vía un WAL con checksums CRC32C, y no cuesta nada de operar más allá del hardware que ya tenés. Es Apache 2.0, está en PyPI, y está listo para que lo pruebes hoy.