Sobre CapyDB

Porque la mayoría de quienes construyen no necesitan una plataforma de backend completa, ni una API de base de datos propietaria, ni una filosofía de infraestructura recién inventada. Necesitan Postgres.

Así que redujimos el Postgres gestionado a una única primitiva: la celda de base de datos, un runtime de Postgres aislado con su propio proceso, almacenamiento, credenciales y límites de CPU/RAM, dedicado a un solo proyecto. La API gestiona celdas; tú usas URL de Postgres normales.

Todo lo demás del producto es el ciclo de vida alrededor de esa primitiva: aprovisionamiento, conexiones directas y mediante pooler, bases de preview, backups, importaciones, restauraciones y extensiones.

• -Vibe coders que convierten un proyecto de fin de semana en una aplicación de verdad
• -Cacharreros que quieren una cadena de conexión, no una ceremonia
• -Indie hackers y equipos pequeños que despliegan rápido
• -Equipos que quieren una base de datos aburrida y un stack propio

• -Aislamiento: cada proyecto en su propia celda, con proceso, credenciales, cuota de almacenamiento, CPU y memoria propios
• -Sencillez: conexiones postgres:// estándar y herramientas de siempre
• -Rendimiento: acceso directo y mediante pooler, con un plano de control ligero
• -Fiabilidad: backups verificados, restauración a un punto en el tiempo, previews desechables y flujos predecibles

No somos un BaaS. Si quieres autenticación, almacenamiento, funciones y todo lo demás, usa un producto hecho para eso.

Tampoco un motor de almacenamiento exótico reescrito. Procesos Postgres reales sobre hardware real, aislados por proyecto: el esfuerzo de ingeniería se ha ido en hacer excelente una primitiva, no en que existan muchas funcionalidades.