Database

PostgreSQL extensions

Kuunda Cloud follows the model teams expect from managed Postgres: rich image, minimal preload, on-demand activation. The tenant is a proj_* schema — not an isolated database. That changes where an extension can be installed.

1. Three layers (do not mix them up)

2. Shared pool vs dedicated instance

A PostgreSQL extension is database-level, not schema-level. On the shared pool, several proj_* projects share the same database: a CREATE EXTENSION would affect all of them.

3. In the console

1. Project → Database → Extensions
2. Review already installed extensions ( extensions schema except the exceptions below)
3. Dedicated instance: pick a packaged extension, then install. Dependencies (e.g. PostGIS before raster) are applied without CASCADE

4. SQL, search_path and API

After creation, types and functions usually live in extensions. The project search_path is:

proj_<id_sans_tirets>, public, extensions

The REST API adds the same extra-search-path (public, extensions). You can therefore write citext or vector without a prefix, as on a Supabase project.

-- 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 is PostgreSQL’s native language: it does not appear as a UI catalog row.

5. Catalog

The console only offers names packaged on the instance and allowed. An extension missing from pg_available_extensions is not listed.

Always there (CORE)

Created at provisioning (the project is not delivered without them). Present on the shared pool and on dedicated. No “install” button: they are already there.

Optional (provisioner)

Installed if the package is available. pg_stat_statements requires the preload (already in place). pg_graphql lives in its own schema.

On demand — contrib (dedicated instance)

Standard PostgreSQL 16 extensions, activable from the console on dedicated / cluster.

On demand — Kuunda image (PostGIS, etc.)

Tenant image packages. PostGIS can take 1–2 minutes and RAM. Do not install it on the shared pool (the UI refuses).

Packaged, no UI (dormant)

Never offered

Isolation, attack surface or boot. Absent from the allowlist, including in the SQL editor.

Intentionally absent from the image

Not a “full Supabase” clone. Among the missing: pgroongarumpgroutingpgjwtpgmqindex_advisorpg_partmanpg_jsonschemapg_hashidspg_tle*_wrapper.

6. Dependencies and imposed schemas

Kuunda installs the listed dependencies, without CASCADE.

Some extensions cannot be relocated into extensions (the .controlfile):

7. Import from Supabase / pg_dump

Import rewrites extensions.* references to match the Kuunda search_path . The dump’s CREATE EXTENSION statements are not replayed as-is: first install the needed pieces via Database → Extensions (dedicated) the needed pieces (pgcrypto is already CORE).

Guide: Supabase migration · Data import.

8. FAQ

Can I paste CREATE EXTENSION vector like on Supabase?

On dedicated: use the UI (safe equivalent). On the shared pool: vector is already installed at provisioning; a second CREATE from the editor is blocked.

Where are uuid-ossp / pgcrypto if I come from public?

New creations go into extensions. Kuunda does not move an extension already created in public. The search_path covers both.

How long does PostGIS take?

Up to about two minutes. One CREATE at a time; a platform lock avoids races.

How do I get citext / PostGIS on an existing project?

Shared-pool projects stay catalog-read-only. You need a dedicated instance (support / plan change), then the Extensions screen.

Open the console