Endpoints

Un endpoint est le processus Postgres qui accepte les connexions clientes. Les endpoints sont éphémères : ils se suspendent à l'inactivité, se réveillent au premier paquet et tournent sur la couche de stockage séparée du projet. Ne payez que pour les secondes pendant lesquelles le calcul tourne réellement.

Types

Les deux types s'attachent à exactement une branche. Un endpoint ne peut pas migrer vers une autre branche ; créez plutôt un nouvel endpoint sur la branche cible.

Suspension à l'inactivité

Les endpoints se suspendent après une fenêtre configurable sans activité cliente. Le défaut est de 300 secondes (5 minutes). Définissez suspend_after_seconds à la création pour le remplacer ; la nouvelle fenêtre prend effet à la prochaine période d'inactivité de l'endpoint.

Pendant la suspension :

• Le pod de calcul a disparu. Aucun CPU, aucune mémoire facturée.
• Le stockage n'est pas affecté — vos données sont durables dans le pageserver.
• L'id de l'endpoint et la chaîne de connexion restent valides.

Réveil

Envoyer un paquet à un endpoint suspendu le réveille. La latence de démarrage à froid est généralement de 300 à 500 ms une fois que le cluster dispose du cache pageserver chaud ; le tout premier réveil après une longue inactivité (ou après un projet neuf) peut prendre de 10 à 30 secondes pendant que le cache de pages du pageserver se réchauffe. Les drivers Postgres standard ne voient pas cela comme un délai dépassé dans les configurations typiques — voir Dépannage si c'est votre cas.

Les réveils de routine sont rapides parce que la plateforme garde un pool de calcul préchauffé en avance sur la demande : un réveil s'attache généralement à un calcul déjà en cours plutôt que de le démarrer de zéro. Vous ne gérez ni ne payez le pool — il n'affecte que la vitesse à laquelle votre endpoint revient.

Machine à états

Un endpoint transite par :

Pending → Starting → Running → Stopping → Stopped → (Failed)

• Pending — le plan de contrôle a accepté la requête de création et planifie le pod de calcul. Si vous voyez un endpoint coincé ici plus de quelques secondes, voir Dépannage.
• Starting — le pod de calcul est en route ; Postgres s'initialise et rejoue le WAL jusqu'au HEAD de la branche.
• Running — accepte les connexions clientes.
• Stopping — la fenêtre d'inactivité s'est écoulée ; drainage des connexions et vidage de l'état local.
• Stopped — suspendu. En attente du prochain paquet pour se réveiller.
• Failed — erreur terminale. La carte de l'endpoint expose la raison ; rare, mais arrive quand la planification échoue ou que l'image de calcul ne peut pas démarrer.

URI de connexion

Le format filaire est documenté dans Chaînes de connexion :

postgresql://<role>:<pwd>@<endpoint_id>.kisenon.com:5432/<database>?sslmode=require

Le nom d'hôte est dérivé de l'id de l'endpoint, pas de l'id du projet — chaque endpoint termine TLS indépendamment. TLS est requis.

Créer

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

Drapeaux optionnels :

• --suspend-after-seconds <n> pour remplacer la fenêtre de suspension par défaut.
• --type ro pour un endpoint en lecture seule.

La CLI renvoie l'id de l'endpoint et la chaîne de connexion. L'endpoint est Running et prêt à accepter des connexions quelques secondes après le retour de l'appel.

Supprimer

keon endpoints delete <endpoint-id>

Les connexions clientes ouvertes sont coupées. L'id de l'endpoint est retiré et son nom d'hôte DNS cesse de résoudre. La branche et ses données ne sont pas affectées.

Liens connexes

• Branches — ce à quoi un endpoint s'attache.
• Chaînes de connexion — détail du format filaire.
• Dépannage — états coincés, délais de démarrage à froid et compagnie.