CapyDB
Comece de graça

Novidades

Mudanças recentes.

Mudanças que estão realmente no produto e no site. Sem promessa vazia, sem roadmap para interpretar.

Cloudflare Workers, Netlify e oito idiomas

  • -Conecte uma conta Cloudflare e o CapyDB coloca uma configuração do Hyperdrive na frente da sua célula, vincula-a ao seu projeto Worker ou Pages e a mantém em dia. As credenciais ficam do lado da Cloudflare, então girá-las chega ao seu Worker sem novo deploy.
  • -As origens do Hyperdrive apontam para o endpoint do pooler, com um orçamento de conexões dimensionado pelo seu plano em vez do padrão da Cloudflare - que pode ultrapassar toda a cota de conexões de um plano pequeno.
  • -Uma ressincronização não altera mais nada se nada mudou de fato. Rotações, restaurações e importações deixaram de publicar silenciosamente uma nova versão do seu Worker.
  • -Uma extensão do CapyDB para a Netlify: guarde uma chave de API no nível do time, escolha um banco por site e as strings de conexão são resolvidas no momento do build. Nas variáveis de ambiente do seu site não entra nada além de um sinalizador de ativação.
  • -Bancos instalados pelo Vercel Marketplace podem ser transferidos entre contas da Vercel. A célula, seu armazenamento e suas strings de conexão acompanham o projeto, então os deploys continuam funcionando; chaves de API com escopo de projeto são revogadas.
  • -O site e o painel agora falam inglês, alemão, espanhol, francês, japonês, coreano, português e chinês. As URLs em inglês não mudaram.
  • -Corrigimos a janela de recuperação para um ponto no tempo na documentação: são 7 dias, não os cerca de 30 que a página de recuperação de desastres afirmava. O caminho de restauração sempre usou apenas pontos de verificação de armazenamento, então 7 dias sempre foi a resposta real.

TLS verificado, previews quentes e benchmarks publicados

  • -As strings de conexão agora usam sslmode=verify-full contra o certificado raiz da CapyDB, e os projetos existentes foram atualizados no lugar - uma conexão não pode mais ser interceptada em silêncio.
  • -Publicamos uma página de benchmarks com a metodologia completa e percentis exatos, medidos em nós de produção e pelo mesmo proxy TLS por onde passa todo projeto.
  • -Os números principais: p95 abaixo de um milissegundo para uma consulta em conexão quente, 2.301 transações por segundo com 32 clientes e 15 ms para abrir uma nova conexão via pooler e receber a resposta.
  • -Publicamos também o número do vizinho barulhento, que quase ninguém publica: com uma célula vizinha sob carga alta contínua, uma célula manteve 49% da vazão que tem sozinha. Isso é divisão proporcional, medida de verdade, em vez de uma promessa de isolamento que ninguém mediu.
  • -Abrimos o código do capybench, a bancada por trás desses números, para qualquer pessoa refazer as medições contra nós ou contra outros.
  • -Os bancos de preview sobem quentes: uma preview deriva do armazenamento da célula mãe, então sua primeira varredura completa de tabela levou 255 ms, a mesma velocidade de uma varredura quente na mãe.
  • -Células pausadas voltam mais rápido: o despertar é antecipado a partir do próprio padrão de tráfego da célula, e uma varredura pesada pontual não empurra mais o conjunto de trabalho para fora do cache.
  • -Pacotes cliente atualizados - @capydb/sdk 1.5.0, @capydb/mcp 1.4.1 e @capydb/drizzle 1.6.0.

Postgres 18, de primeira classe

  • -capydb.uuidv7() agora existe em toda célula e resolve para a implementação certa no Postgres 16, 17 e 18 - assim um default de UUID ordenável por tempo sobrevive a uma atualização maior em vez de quebrar do outro lado.
  • -Células no Postgres 18 rodam a nova E/S assíncrona dimensionada pelo plano, e as visões de progresso de vacuum da versão ficam disponíveis para consulta.
  • -Publicamos um guia de Postgres 18: UUIDs ordenáveis por tempo, restrições temporais, colunas geradas virtuais e devolver a linha antiga - e como usar tudo isso sem prender o esquema a uma única versão maior.
  • -capydb doctor ganhou regras para as decisões de esquema que custam mais caro depois: defaults uuidv7() não portáveis e colunas anuláveis que não deveriam ser.
  • -Colunas geradas agora aparecem na introspecção de esquema e no capydb generate, então os tipos gerados batem com o banco.
  • -Conexões via pooler falam o protocolo de rede do Postgres 18.

Consultor de índices e conversão de RLS do Supabase

  • -Adicionamos um consultor de índices que sugere índices a partir das consultas que seu banco realmente executou, ordenados pelo que economizariam.
  • -Cada candidato é medido como índice hipotético - nada é criado e nada é escrito - então dá para rodar em produção com segurança.
  • -O consultor está no painel, em capydb advisor indexes, na API e como ferramenta MCP para agentes.
  • -Adicionamos capydb migrate rls, que converte políticas de row-level security do Supabase para Postgres puro e informa exatamente quais claims sua aplicação passa a ter que fornecer.
  • -Abrimos o código do capyrls, o conversor por trás disso.
  • -Adicionamos uma página de esquema ao painel para navegar por tabelas, colunas, índices e enums do banco em execução.
  • -@capydb/drizzle ganhou withAuthContext, um jeito seguro no pooler de rodar consultas sob uma identidade de row-level security.
  • -Notificações de alerta também vão para o e-mail de cobrança da organização, além do painel e dos seus webhooks.

Atualizações de versão, entregas de webhook e conferência do repositório

  • -As atualizações menores do Postgres são no seu tempo: uma célula pausada leva uma de graça no próximo despertar, e uma célula em atividade informa a versão pendente e reinicia quando você mandar.
  • -Adicionamos uma verificação de prontidão para versão maior que aponta os bloqueios antes de qualquer coisa ser construída, para a atualização não falhar no meio.
  • -Documentamos como uma atualização maior funciona aqui: uma cópia completa com janela de verificação, uma virada que você confirma e um retorno que continua disponível depois.
  • -Endpoints de webhook agora guardam histórico de entrega com o status de cada tentativa, e uma entrega específica pode ser reenviada.
  • -Adicionamos capydb webhooks test para mandar um evento de teste assinado a um endpoint.
  • -Adicionamos capydb doctor, que lê um repositório e aponta a configuração de banco que dói depois: arquivos .env apontando a mesma variável para bancos diferentes, ferramentas de migração misturadas de forma insegura e drivers na porta errada.

Postgres 16-18, conexões via pooler e uma leva de ferramentas para desenvolvimento

  • -Escolha da versão maior do Postgres: crie projetos no Postgres 16, 17 ou 18.
  • -Pooling de conexões por projeto na porta 6432, com tamanhos de pool alinhados ao seu plano.
  • -Introspecção de schema e geração de tipos: capydb generate emite definições de TypeScript, Zod ou Drizzle direto do seu schema em produção.
  • -Lançado o @capydb/drizzle, uma configuração de Drizzle ORM com padrões seguros para o pooler nas conexões da CapyDB.
  • -Importações com quase nenhuma indisponibilidade via capydb import --follow, que segue replicando as mudanças do banco antigo até a virada.
  • -Rotação de credenciais sem indisponibilidade: as credenciais antigas continuam valendo por um período enquanto você publica as novas.
  • -Acompanhamento de logs ao vivo e análise de consultas no painel e pelo capydb logs.
  • -As extensões do Postgres passam a ser atualizadas automaticamente, sinalizadas como avisos de atualização da plataforma no painel.

Pausa quando ocioso, e confirmação antes do destrutivo

  • -As células agora pausam quando ninguém está consultando e voltam na conexão seguinte, em cerca de um terço de segundo. Um banco parado deixa de custar computação.
  • -Os estados pausado e retomando aparecem em todo lugar - painel, API e CLI - então um banco retomando é lido como retomando, não como falha.
  • -Adicionamos restauração para um ponto no tempo sobre o próprio banco de produção, atrás de uma confirmação explícita.
  • -Operações destrutivas passam a exigir essa confirmação: uma importação que sobrescreveria dados, ou apagar um projeto de produção, falha sem ela em vez de seguir caladamente.
  • -Adicionamos pg_cron ao catálogo de extensões.
  • -Adicionamos um fluxo de eventos do projeto e o histórico de tarefas, para acompanhar uma operação longa em vez de ficar perguntando.

Um Postgres por célula

  • -Cada célula agora roda como seu próprio Postgres, com armazenamento próprio e limites próprios de CPU e memória, em vez de dividir um servidor com outros projetos.
  • -Limites de conexão e memória vêm do seu plano, não do que os vizinhos deixaram sobrando.
  • -Previews e restaurações viraram ramificações do armazenamento de uma célula - é por isso que nascem rápido, com qualquer volume de dados atrás.
  • -Uma célula nova só é colocada em um nó com folga para atendê-la, e os limites por célula garantem que o pico de um vizinho não leve o nó inteiro.
  • -Painel, API, CLI e provider do Terraform passaram a falar o mesmo vocabulário: células, em nós, em regiões.

Extensões, alertas de uso e uma leva de ferramentas de plataforma

  • -Painel repaginado, com barra lateral de contexto do projeto e um checklist inicial em todo projeto novo.
  • -Gerenciamento de extensões do Postgres: ative PostGIS, pgcrypto e outras extensões selecionadas por projeto, direto do painel.
  • -Alertas de limite de uso em armazenamento e conexões, entregues no painel, por webhook (alert.triggered / alert.resolved) e por e-mail.
  • -Lançada uma página de status ao vivo, com a saúde de cada região.
  • -CLI ampliada com uma nova leva de comandos para o dia a dia de operação.
  • -Lançado o @capydb/mcp para que agentes de IA gerenciem projetos, previews e backups por MCP.
  • -Lançado um provider de Terraform para gerenciar projetos e previews de forma declarativa.
  • -GitHub Action de banco de preview por pull request mais robusta.
  • -Nova documentação sobre pooling, recuperação de desastres, viradas, conformidade e llms.txt.

Chaves de API, webhooks e integrações

  • -Adicionamos chaves de API com escopo por chave, listagem e revogação.
  • -Adicionamos endpoints de webhook com eventos assinados para o ciclo de vida de projetos e tarefas, cada um com segredo próprio e rotação.
  • -Adicionamos integrações com Vercel e Netlify que enviam as strings de conexão para o ambiente do seu projeto e as reenviam depois de rotações, restaurações e importações.
  • -Adicionamos integrações de sincronização de usuários para Clerk, Auth0 e Better Auth.

Repaginada de marca e marketing

  • -Site público reposicionado em torno de Postgres gerenciado sem enrolação.
  • -Textos de preços, sobre, contato, documentação e blog reescritos com uma voz mais direta, voltada a quem constrói.
  • -Mensagem alinhada a bancos descartáveis, acesso direto e limites de produto bem definidos.

Autenticação de organização pela Clerk no painel

  • -O backend passou a verificar os tokens de sessão da Clerk.
  • -Organizações ativas da Clerk mapeadas para organizações da CapyDB nos metadados.
  • -O frontend não exige mais um token de admin global nas rotas normais do painel.

Área administrativa e configurações de organização

  • -Interface administrativa para listar e criar organizações e nós da grade.
  • -Troca entre várias organizações pelo OrganizationSwitcher da Clerk.
  • -Edição dos metadados de cobrança, gestão de time e revogação de chaves de API nas configurações.

Faxina no site público

  • -Rotas provisórias de documentação, blog, jurídico, sobre, contato e novidades substituídas por conteúdo real.
  • -Removidas as referências a recursos de CLI ainda não lançados e aos avisos de “em breve”.