Base de données

Extensions PostgreSQL

Kuunda Cloud s’aligne sur le modèle que les équipes attendent d’un Postgres managé : image riche, preload minimal, activation à la demande. Le tenant est un schéma proj_* — pas une base isolée. Cela change où l’on peut installer une extension.

1. Trois couches (à ne pas confondre)

2. Pool partagé vs instance dédiée

Une extension PostgreSQL est au niveau de la base, pas du schéma. Sur le pool partagé, plusieurs projets proj_* partagent la même base : un CREATE EXTENSION les toucherait tous.

3. Dans la console

1. Projet → Database → Extensions
2. Consulter les extensions déjà installées (schéma extensions sauf exception ci-dessous)
3. Instance dédiée : choisir une extension packagée, puis installer. Les dépendances (ex. PostGIS avant raster) sont posées sans CASCADE

4. SQL, search_path et API

Après création, les types et fonctions sont en général dans extensions. Le search_path du projet est :

proj_<id_sans_tirets>, public, extensions

L’API REST ajoute le même extra-search-path (public, extensions). Vous pouvez donc écrire citext ou vector sans préfixe, comme sur un projet Supabase.

-- Exemple une fois citext activée (instance dédiée)
CREATE TABLE contacts (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  email citext NOT NULL UNIQUE
);

plpgsql est le langage natif de PostgreSQL : il n’apparaît pas comme une ligne du catalogue UI.

5. Catalogue

La console ne propose que les noms packagés sur l’instance et autorisés. Une extension absente de pg_available_extensions n’est pas listée.

Toujours là (CORE)

Créées au provisionnement (le projet n’est pas livré sans elles). Présentes sur le pool partagé comme sur le dédié. Pas de bouton « installer » : elles le sont déjà.

Optionnelles (provisionneur)

Posées si le paquet est disponible. pg_stat_statements exige le preload (déjà en place). pg_graphql vit dans son propre schéma.

À la demande — contrib (instance dédiée)

Extensions du PostgreSQL 16 standard, activables depuis la console sur dédié / cluster.

À la demande — image Kuunda (PostGIS, etc.)

Paquets de l’image tenants. PostGIS peut prendre 1 à 2 minutes et de la RAM. Ne l’installez pas sur le pool partagé (l’UI refuse).

Packagées, pas d’UI (dormantes)

Jamais proposées

Isolation, surface d’attaque ou boot. Absentes de l’allowlist, y compris en SQL éditeur.

Volontairement absentes de l’image

Pas de clone « tout Supabase ». Parmi les absents : pgroongarumpgroutingpgjwtpgmqindex_advisorpg_partmanpg_jsonschemapg_hashidspg_tle*_wrapper.

6. Dépendances et schémas imposés

Kuunda installe les dépendances listées, sans CASCADE.

Certaines extensions ne sont pas relogeables dans extensions (fichier .control) :

7. Import depuis Supabase / pg_dump

L’import réécrit les références extensions.* pour coller au search_path Kuunda. Les CREATE EXTENSION du dump ne sont pas rejoués tels quels : installez d’abord via Database → Extensions (dédié) les pièces nécessaires (pgcrypto est déjà CORE).

Guide : Migration Supabase · Import de données.

8. Questions fréquentes

Puis-je coller CREATE EXTENSION vector comme chez Supabase ?

Sur dédié : utilisez l’UI (équivalent sûr). Sur le pool partagé : vector est déjà posé au provisionnement ; un second CREATE depuis l’éditeur est bloqué.

Où sont uuid-ossp / pgcrypto si je viens de public ?

Les nouvelles créations vont dans extensions. Kuunda ne déplace pas une extension déjà créée dans public. Le search_path couvre les deux.

Combien de temps pour PostGIS ?

Jusqu’à environ deux minutes. Un seul CREATE à la fois ; un verrou côté plateforme évite les courses.

Comment obtenir citext / PostGIS sur un projet actuel ?

Les projets du pool partagé restent en lecture catalogue. Il faut une instance dédiée (support / évolution d’offre), puis l’écran Extensions.

Ouvrir la console