CapyDB
Empieza gratis

Novedades

Cambios recientes.

Cambios que están realmente en el producto y en la web. Sin humo y sin hojas de ruta para interpretar.

Cloudflare Workers, Netlify y ocho idiomas

  • -Conecta una cuenta de Cloudflare y CapyDB coloca una configuración de Hyperdrive delante de tu celda, la vincula a tu proyecto de Worker o Pages y la mantiene al día. Las credenciales se quedan del lado de Cloudflare, así que rotarlas llega a tu Worker sin volver a desplegar.
  • -Los orígenes de Hyperdrive apuntan al endpoint con pooler con un presupuesto de conexiones acorde a tu plan, en lugar del valor por defecto de Cloudflare, que puede superar el cupo completo de conexiones de un plan pequeño.
  • -Una resincronización ya no cambia nada si nada ha cambiado. Las rotaciones, restauraciones e importaciones dejan de publicar en silencio una versión nueva de tu Worker.
  • -Una extensión de CapyDB para Netlify: guarda una clave de API por equipo, elige una base de datos por sitio y las cadenas de conexión se resuelven en tiempo de compilación. En las variables de entorno de tu sitio no aparece nada más que un indicador de activación.
  • -Las bases de datos instaladas desde el Vercel Marketplace se pueden transferir entre cuentas de Vercel. La celda, su almacenamiento y sus cadenas de conexión viajan con el proyecto, así que los despliegues siguen funcionando; las claves de API con alcance de proyecto se revocan.
  • -El sitio y el panel hablan ahora inglés, alemán, español, francés, japonés, coreano, portugués y chino. Las URL en inglés no han cambiado.
  • -Corregida la ventana de recuperación a un punto en el tiempo en la documentación: son 7 días, no los ~30 que indicaba la página de recuperación ante desastres. La restauración solo usó nunca puntos de control de almacenamiento, así que 7 días siempre fue la respuesta real.

TLS verificado, previews en caliente y benchmarks publicados

  • -Las cadenas de conexión ahora usan sslmode=verify-full contra el certificado raíz de CapyDB, y los proyectos existentes se actualizaron sobre la marcha: una conexión ya no puede interceptarse en silencio.
  • -Publicada una página de benchmarks con la metodología completa y percentiles exactos, medidos en nodos de producción y a través del mismo proxy TLS por el que pasa cada proyecto.
  • -Los números de cabecera: p95 por debajo del milisegundo para una consulta sobre conexión caliente, 2.301 transacciones por segundo con 32 clientes y 15 ms para abrir una conexión nueva a través del pooler y obtener respuesta.
  • -También publicado el número del vecino ruidoso, que casi nadie publica: con una celda vecina bajo carga alta sostenida, una celda conservó el 49 % de su rendimiento en solitario. Eso es reparto proporcional, medido de verdad, en lugar de una promesa de aislamiento sin medir.
  • -Liberado capybench como código abierto, el arnés detrás de esos números, para que cualquiera los repita contra nosotros o contra quien quiera.
  • -Las bases de preview arrancan en caliente: una preview se ramifica del almacenamiento de su celda madre, así que su primer recorrido completo de tabla tardó 255 ms, lo mismo que un recorrido caliente sobre la madre.
  • -Las celdas en pausa vuelven antes: el despertar se anticipa a partir del propio patrón de tráfico de la celda, y un recorrido masivo puntual ya no expulsa de la caché el conjunto de trabajo.
  • -Actualizados los paquetes cliente: @capydb/sdk 1.5.0, @capydb/mcp 1.4.1 y @capydb/drizzle 1.6.0.

Postgres 18, de pleno derecho

  • -capydb.uuidv7() ya existe en cada celda y resuelve a la implementación correcta en Postgres 16, 17 y 18, así que un valor por defecto de UUID ordenable por tiempo sobrevive a una actualización mayor en lugar de romperse al otro lado.
  • -Las celdas con Postgres 18 ejecutan la nueva E/S asíncrona dimensionada según su plan, y las vistas de progreso de vacuum de esa versión están disponibles para consulta.
  • -Publicada una guía de Postgres 18: UUID ordenables por tiempo, restricciones temporales, columnas generadas virtuales y devolver la fila antigua, y cómo usarlas sin clavar el esquema a una sola versión mayor.
  • -capydb doctor incorpora reglas para las decisiones de esquema que más cuestan después: valores por defecto uuidv7() no portables y columnas nulables que no deberían serlo.
  • -Las columnas generadas ya aparecen en la introspección de esquema y en capydb generate, de modo que los tipos generados coinciden con la base de datos.
  • -Las conexiones con pooler hablan el protocolo nativo de Postgres 18.

Asesor de índices y conversión de RLS de Supabase

  • -Añadido un asesor de índices que propone índices a partir de las consultas que tu base de datos ejecutó de verdad, ordenados por lo que ahorrarían.
  • -Cada candidato se mide como índice hipotético - no se crea nada y no se escribe nada -, así que el asesor es seguro contra producción.
  • -El asesor está en el panel, en capydb advisor indexes, en la API y como herramienta MCP para agentes.
  • -Añadido capydb migrate rls, que convierte las políticas de row-level security de Supabase a Postgres puro e informa exactamente de qué claims tiene que aportar tu aplicación a partir de ahora.
  • -Liberado capyrls como código abierto, el conversor que hay detrás.
  • -Añadida una página de esquema al panel para recorrer tablas, columnas, índices y enums de la base de datos viva.
  • -@capydb/drizzle incorpora withAuthContext, una forma segura con el pooler de ejecutar consultas bajo una identidad de row-level security.
  • -Las notificaciones de alerta también van ahora al correo de facturación de la organización, además del panel y tus webhooks.

Actualizaciones de versión, entregas de webhook y revisión del repositorio

  • -Las actualizaciones menores de Postgres las decides tú: una celda en pausa se lleva una gratis al despertar, y una celda en marcha informa de la versión pendiente y se reinicia cuando tú digas.
  • -Añadida una comprobación de preparación para versión mayor que informa de los bloqueos antes de construir nada, para que una actualización mayor no falle a mitad de camino.
  • -Documentado cómo funcionan aquí las actualizaciones mayores: una copia completa con ventana de verificación, un cambio que confirmas tú y una vuelta atrás que sigue disponible después.
  • -Los endpoints de webhook guardan ahora el historial de entregas con el estado de cada intento, y una entrega concreta puede reenviarse.
  • -Añadido capydb webhooks test para enviar un evento de prueba firmado a un endpoint.
  • -Añadido capydb doctor, que lee un repositorio y señala la configuración de base de datos que duele más tarde: archivos .env que apuntan la misma variable a dos bases distintas, herramientas de migración mezcladas de forma insegura y drivers apuntando al puerto equivocado.

Postgres 16-18, conexiones con pooler y una tanda de herramientas para desarrollo

  • -Selección de versión mayor de Postgres: crea proyectos sobre Postgres 16, 17 o 18.
  • -Pooling de conexiones por proyecto en el puerto 6432, con tamaños de pool ajustados a tu plan.
  • -Introspección de esquema y generación de tipos: capydb generate emite definiciones de TypeScript, Zod o Drizzle directamente desde tu esquema en vivo.
  • -Publicado @capydb/drizzle, una configuración de Drizzle ORM con valores seguros para el pooler en conexiones de CapyDB.
  • -Importaciones con interrupción casi nula mediante capydb import --follow, que sigue replicando cambios de tu base antigua hasta que haces el cambio.
  • -Rotación de credenciales sin interrupción: las credenciales antiguas siguen funcionando durante un margen mientras despliegas las nuevas.
  • -Seguimiento de logs en vivo e información de consultas en el panel y con capydb logs.
  • -Las extensiones de Postgres ahora se actualizan automáticamente, con avisos de actualización de plataforma en el panel.

Pausa al no usarse, y confirmación antes de lo destructivo

  • -Las celdas se pausan cuando nadie las consulta y vuelven en la siguiente conexión, en torno a un tercio de segundo. Una base ociosa deja de costar cómputo.
  • -Los estados en pausa y reanudando se informan en todas partes - panel, API y CLI -, así que una base reanudando se lee como reanudando y no como un fallo.
  • -Añadida la restauración a un punto en el tiempo sobre la propia base de producción, tras una confirmación explícita.
  • -Las operaciones destructivas exigen ahora esa confirmación: una importación que sobrescribiría datos, o borrar un proyecto de producción, falla sin ella en lugar de seguir en silencio.
  • -Añadido pg_cron al catálogo de extensiones.
  • -Añadidos un flujo de eventos del proyecto y el historial de trabajos, para poder mirar una operación larga en vez de sondearla.

Un Postgres por celda

  • -Cada celda corre ahora como su propio Postgres, con su propio almacenamiento y sus propios límites de CPU y memoria, en lugar de compartir un servidor con otros proyectos.
  • -Los límites de conexiones y la memoria salen de tu plan, no de lo que hayan dejado los vecinos.
  • -Previews y restauraciones pasaron a ser ramas del almacenamiento de una celda, que es por lo que se crean rápido sin importar cuántos datos haya detrás.
  • -Una celda nueva solo se coloca en un nodo con margen para servirla, y los límites por celda hacen que el pico de un vecino no se lleve el nodo entero.
  • -Panel, API, CLI y el proveedor de Terraform pasaron a hablar un solo vocabulario: celdas, en nodos, en regiones.

Extensiones, alertas de uso y una tanda de herramientas de plataforma

  • -Panel renovado con barra lateral de contexto de proyecto y una lista de puesta en marcha en cada proyecto nuevo.
  • -Gestión de extensiones de Postgres: activa PostGIS, pgcrypto y otras extensiones seleccionadas por proyecto desde el panel.
  • -Alertas de umbral de uso en almacenamiento y conexiones, entregadas en el panel, por webhook (alert.triggered / alert.resolved) y por correo.
  • -Lanzada una página de estado en vivo con la salud de cada región.
  • -CLI ampliada con una nueva tanda de comandos para el día a día.
  • -Publicado @capydb/mcp para que los agentes de IA gestionen proyectos, previews y backups por MCP.
  • -Publicado un proveedor de Terraform para gestionar proyectos y previews de forma declarativa.
  • -Reforzada la GitHub Action que crea una base de preview por pull request.
  • -Nueva documentación sobre pooling, recuperación ante desastres, migraciones, cumplimiento y llms.txt.

Claves de API, webhooks e integraciones de proveedor

  • -Añadidas claves de API con alcances por clave, listado y revocación.
  • -Añadidos endpoints de webhook con eventos firmados para el ciclo de vida de proyectos y trabajos, cada uno con su secreto y su rotación.
  • -Añadidas integraciones con Vercel y Netlify que escriben las cadenas de conexión en el entorno de tu proyecto y las vuelven a escribir tras rotaciones, restauraciones e importaciones.
  • -Añadidas integraciones de sincronización de usuarios para Clerk, Auth0 y Better Auth.

Renovación de marca y marketing

  • -Reposicionada la web pública en torno a un Postgres gestionado sin humo.
  • -Reescritos los textos de precios, quiénes somos, contacto, documentación y blog con una voz más directa y cercana a quien construye.
  • -Mensaje alineado con bases desechables, acceso directo y límites de producto claros.

Autenticación de organización con Clerk en el panel

  • -El backend ya verifica los tokens de sesión de Clerk.
  • -Las organizaciones activas de Clerk se corresponden con organizaciones de CapyDB en los metadatos.
  • -El frontend ya no necesita un token de admin global en las rutas normales del panel.

Superficie de administración y ajustes de organización

  • -Interfaz de administración para listar y crear organizaciones y nodos de la malla.
  • -Cambio entre varias organizaciones mediante el OrganizationSwitcher de Clerk.
  • -Edición de metadatos de facturación, gestión de equipo y revocación de claves de API en los ajustes.

Limpieza de la web pública

  • -Sustituidas por contenido real las rutas provisionales de documentación, blog, legal, quiénes somos, contacto y novedades.
  • -Eliminadas las referencias a funciones de CLI no publicadas y a «próximamente» de la web.