Endpoints

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

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). Establece suspend_after_seconds en el momento de la creación para anularlo; 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. La latencia de arranque en frío es típicamente de 300–500 ms una vez que el clúster tiene la caché caliente del pageserver; 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=require

El 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

keon endpoints create --branch <branch-id> --type rw

Flags opcionales:

• --suspend-after-seconds <n> para anular la ventana de suspensión predeterminada.
• --type ro para un endpoint de solo lectura.

La 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.