Endpoints
Frontends de Postgres con suspensión al estar inactivo — tipos, ciclo de vida y semántica de activación.
Un endpoint es el proceso de Postgres que acepta conexiones de clientes. Los endpoints son efímeros: se suspenden cuando están inactivos, se activan con el primer paquete, y se ejecutan sobre la capa de almacenamiento separada del proyecto. Paga solo por los segundos en que el cómputo está realmente en ejecución.
Tipos
| Tipo | ¿Escrituras? | Cuándo usarlo |
|---|---|---|
rw | Sí | El predeterminado: cada rama nueva recibe uno automáticamente. Tráfico de app, migraciones, cualquier cosa que mute. Un endpoint rw por rama es más que suficiente para cargas de trabajo típicas. |
ro | No | Réplicas de lectura. Múltiples endpoints ro pueden adjuntarse a la misma rama y compartir almacenamiento; sus cachés locales permanecen independientes. Úsalo para aislar el tráfico analítico del tráfico de app. |
Ambos tipos se adjuntan a exactamente una rama. Un endpoint no puede moverse a una rama diferente; crea un nuevo endpoint en la rama de destino en su lugar.
Suspensión al estar inactivo
Los endpoints se suspenden tras una ventana configurable sin actividad de cliente.
El predeterminado es 300 segundos (5 minutos). Cámbialo con
keon endpoints update <endpoint-id> --suspend-timeout <seconds>:
0 significa no suspender nunca; cualquier otro valor debe estar entre 60 y 3600.
Por la API, suspend_after_seconds en POST /v1/branches/{branchId}/endpoints
lo fija al crear. La nueva ventana surte efecto en el siguiente período de
inactividad del endpoint.
Mientras está suspendido:
- El pod de cómputo desaparece. No se factura CPU ni memoria.
- El almacenamiento no se ve afectado — tus datos son duraderos en el pageserver.
- El id del endpoint y la cadena de conexión siguen siendo válidos.
Activación
Enviar un paquete a un endpoint suspendido lo activa. Una activación que se adjunta a cómputo precalentado suele estar lista en menos de 2 segundos; la primera activación tras una larga inactividad (o tras un proyecto nuevo) puede tardar de 10 a 30 segundos mientras la caché de páginas del pageserver se calienta. Los controladores estándar de Postgres no lo ven como un timeout en configuraciones típicas — consulta Solución de problemas si lo haces.
Las activaciones rutinarias son rápidas porque la plataforma mantiene un pool de cómputo precalentado por delante de la demanda: una activación normalmente se adjunta a cómputo ya en ejecución en lugar de arrancarlo desde cero. Tú no gestionas ni pagas por el pool — solo afecta a la rapidez con que tu endpoint vuelve.
Máquina de estados
Un endpoint transiciona a través de:
Pending → Starting → Running → Stopping → Stopped → (Failed)- Pending — el plano de control ha aceptado la solicitud de creación y está programando el pod de cómputo. Si ves un endpoint atascado aquí durante más de unos segundos, consulta Solución de problemas.
- Starting — el pod de cómputo está en marcha; Postgres se está inicializando y reproduciendo WAL hasta el HEAD de la rama.
- Running — aceptando conexiones de clientes.
- Stopping — la ventana de inactividad transcurrió; drenando conexiones y vaciando el estado local.
- Stopped — suspendido. Esperando el siguiente paquete para activarse.
- Failed — error terminal. La tarjeta del endpoint muestra la razón; poco frecuente, pero sucede cuando la programación falla o la imagen de cómputo no puede arrancar.
URI de conexión
El formato de cable está documentado en Cadenas de conexión:
postgresql://<role>:<pwd>@<endpoint_id>.<region>.kisenon.com:5432/<database>?sslmode=requireEl nombre de host se deriva del id del endpoint, no del id del proyecto — cada endpoint termina TLS de forma independiente. TLS es obligatorio.
El mismo endpoint también responde en
<endpoint_id>-pooler.<region>.kisenon.com para conexiones agrupadas por
transacción (activado por defecto) — consulta
Cadenas de conexión para las contrapartidas agrupado-vs-directo.
Crear
Cada rama nueva recibe automáticamente un endpoint rw. Para añadir otro:
keon branches add-compute <branch-id>Flags opcionales:
--type ro|rw— por defectoro(solo lectura).rwreemplaza el endpoint primario de lectura-escritura de la rama.--min-cu <cu>/--max-cu <cu>— la ventana de autoescalado.--max-cusolo se puede fijar aquí; es fijo durante toda la vida del endpoint.
Para cambiar después la ventana de suspensión:
keon endpoints update <endpoint-id> --suspend-timeout 600La CLI devuelve el id del endpoint y la cadena de conexión. El
endpoint está Running y listo para aceptar conexiones a los pocos
segundos de que la llamada retorne.
Eliminar
keon endpoints delete <endpoint-id>Las conexiones de clientes abiertas se cierran. El id del endpoint se retira y su nombre de host DNS deja de resolverse. La rama y sus datos no se ven afectados.
Relacionado
- Ramas — a qué se adjunta un endpoint.
- Cadenas de conexión — detalle del formato de cable.
- Solución de problemas — estados atascados, timeouts de arranque en frío y afines.