Sobre a CapyDB

Porque a maioria de quem constrói não precisa de uma plataforma de backend completa, nem de uma API de banco proprietária, nem de uma filosofia de infraestrutura recém-inventada. Precisa de Postgres.

Então a gente reduziu o Postgres gerenciado a uma única primitiva: a célula de banco de dados – um runtime Postgres isolado com processo, armazenamento, credenciais e limites de CPU/RAM próprios, dedicado a um único projeto. A API gerencia células; você usa URLs de Postgres normais.

Todo o resto do produto é o ciclo de vida em volta dessa primitiva: provisionamento, conexões diretas e via pooler, bancos de preview, backups, importações, restaurações e extensões.

• -Vibe coders transformando um projeto de fim de semana em app de verdade
• -Quem gosta de mexer e quer uma string de conexão, não uma cerimônia
• -Indie hackers e times pequenos que publicam rápido
• -Times que querem o banco sem graça e a stack do jeito deles

• -Isolamento: cada projeto na própria célula – processo, credenciais, cota de armazenamento, CPU e memória
• -Simplicidade: conexões postgres:// padrão e as ferramentas de sempre
• -Desempenho: acesso direto e via pooler, com um plano de controle enxuto
• -Confiabilidade: backups verificados, restauração para qualquer ponto no tempo, previews descartáveis e fluxos previsíveis

Não é um BaaS. Se você quer autenticação, storage, functions e todo o resto junto, use um produto feito para isso.

Também não é um motor de armazenamento exótico reescrito. Processos Postgres de verdade em hardware de verdade, isolados por projeto – o esforço de engenharia foi para deixar uma primitiva excelente, não para fazer muitas funcionalidades existirem.