Self-hosted PostgreSQL vs Supabase Comparaison

Base de données relationnelle open source, exécutée sur ton propre serveur, mûrie depuis 1986

VS
Supabase

Plateforme backend open source managée, construite sur du vrai PostgreSQL

17 min de lectureBase de données

Verdict rapide

Cette décision n'a pas une seule bonne réponse. Si tu es dans une petite équipe et que la vitesse prime, Supabase est le bon choix : auth, storage, realtime et pooler arrivent prêts à l'emploi. Avec une charge prévisible, une contrainte de résidence des données (la Turquie ne figure pas parmi les 17 régions) ou un coût qui grimpe avec le nombre d'utilisateurs, PostgreSQL auto-hébergé l'emporte. Un avertissement : la documentation officielle indique que la sauvegarde/PITR managée est désactivée en self-host — avec le contrôle, tu hérites de la répétition de restauration. Faire une sauvegarde n'est pas le critère ; pouvoir restaurer l'est.

Self-hosted PostgreSQLSupabase
Lire le verdict complet

Comparaison des scores

Chargement du graphique...

Notation détaillée

Notation détaillée: Self-hosted PostgreSQL et Supabase — notes sur 10, catégorie par catégorie
CatégorieSelf-hosted PostgreSQLSupabase
Performance
8/10
8/10
Facilité d'apprentissage
5/10
8/10
Écosystème
9/10
8/10
Communauté
9/10
9/10
Marché de l'emploi
8/10
7/10
Pérennité
8/10
8/10

Avantages & Inconvénients

Self-hosted PostgreSQL

Avantages

  • Le logiciel est entièrement gratuit (PostgreSQL License) — le coût se fixe sur ton infrastructure
  • Liberté totale d'extensions : pgvector, PostGIS, pg_cron, installe tout ce que tu veux
  • Les données restent physiquement sur le serveur que tu as choisi — la résidence des données est sous ton contrôle direct
  • PITR en fonctionnalité cœur (archivage WAL + pg_basebackup)
  • Aucun vendor lock-in — tu es déjà sur ta propre infrastructure
  • Chaque version majeure bénéficie de 5 ans de support officiel, un calendrier de patchs prévisible
  • RLS est une fonctionnalité cœur depuis la 9.5, tu peux l'utiliser comme tu veux

Inconvénients

  • Auth, Storage, Realtime ne sont pas dans le cœur — à installer et exploiter séparément
  • Un outil séparé comme PgBouncer/Supavisor est nécessaire pour le pooling de connexions
  • Sauvegarde/PITR/HA/monitoring relèvent entièrement de ta responsabilité, aucun SLA officiel
  • Courbe d'apprentissage plus raide : mettre en place auth+pooling+HA à la main prend du temps
  • Aucune page officielle de cas client/benchmark n'est publiée (projet communautaire)

Idéal pour

Projets de taille moyenne à grande nécessitant un budget fixe et prévisibleSystèmes ayant une clause contractuelle de KVKK/résidence des donnéesTravaux nécessitant des combinaisons d'extensions spécifiques comme pgvector/PostGISÉquipes ayant une capacité DevOps et planifiant des répétitions de restaurationProjets de longue durée où l'indépendance vis-à-vis du vendor est critique

Supabase

Avantages

  • Auth, Storage, Realtime, Data API arrivent prêts — tu n'écris pas la couche auth de zéro
  • Démarre à 0 $/mois sur le plan Free (500MB DB, 5GB egress, 50k MAU)
  • Pooling de connexions prêt à l'emploi avec les options Dedicated/Shared pooler (Supavisor)
  • Certifications de conformité prêtes comme HIPAA (BAA), ISO 27001, GDPR DPA
  • Le taux d'erreur des services est surveillé automatiquement via Health Check Advisors (septembre 2026)
  • Observabilité en un clic avec Grafana Cloud (juillet 2026)
  • Comme du vrai PostgreSQL tourne dessous, c'est portable via pg_dump, faible vendor lock-in

Inconvénients

  • Le coût augmente progressivement avec les utilisateurs/données (0,125 $/GB disque, 0,09 $/GB egress, 0,00325 $/MAU)
  • La Turquie ne figure pas parmi les 17 régions — cela pose la question d'un transfert de données à l'étranger au regard du KVKK
  • Aucune sauvegarde automatique sur le plan Free, seulement 7 jours en Pro
  • Les extensions sont limitées au catalogue curé par la plateforme, pas de liberté totale au niveau OS
  • L'option self-host est « community-supported » — pas de SLA officiel, la sauvegarde/PITR managée est désactivée

Idéal pour

Passage rapide de 0 à 1 pour une personne seule ou une petite équipeÉquipes produit ne voulant pas construire Auth/Storage/Realtime de zéroProjets nécessitant des certifications prêtes comme HIPAA/ISO 27001/GDPRÉquipes voulant un monitoring managé et des alertes automatiques de taux d'erreurCeux qui veulent démarrer vite tout en préservant l'indépendance vendor via pg_dump

Comparaison de code

Self-hosted PostgreSQL
# Self-hosted PostgreSQL - Configuration de l'archivage WAL + PITR (postgresql.conf)
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /var/backups/pg_wal_archive/%f && cp %p /var/backups/pg_wal_archive/%f'
max_wal_senders = 3

# Sauvegarde de base (pg_basebackup)
pg_basebackup -D /var/backups/base -Ft -z -P -U replicator -h localhost

# PITR : revenir à un instant précis (recovery.signal + postgresql.conf)
# 1) Restaurer la sauvegarde de base dans le répertoire de restauration
# 2) Ajouter les lignes suivantes à postgresql.conf, créer le fichier recovery.signal
restore_command = 'cp /var/backups/pg_wal_archive/%f %p'
recovery_target_time = '2026-09-23 09:00:00+03'

# pg_hba.conf - connexion uniquement depuis le serveur applicatif
host    appdb    app_user    10.0.0.5/32    scram-sha-256

-- SQL (psql) : installation des extensions (liberté totale - propre au self-host)
CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS postgis;
CREATE EXTENSION IF NOT EXISTS pg_cron;

# Pooling de connexions (PgBouncer, pgbouncer.ini)
[databases]
appdb = host=127.0.0.1 port=5432 dbname=appdb
[pgbouncer]
pool_mode = transaction
max_client_conn = 500
default_pool_size = 25
Supabase
-- SQL (Supabase SQL Editor) : 1) Créer la table et activer RLS (la Data API l'exige)
create table public.notes (
  id uuid default gen_random_uuid() primary key,
  user_id uuid references auth.users not null,
  content text not null,
  created_at timestamptz default now()
);
alter table public.notes enable row level security;

create policy "kullanicilar kendi notlarini okur"
  on public.notes for select
  using (auth.uid() = user_id);

create policy "kullanicilar kendi notlarini yazar"
  on public.notes for insert
  with check (auth.uid() = user_id);

// 2) Requête avec supabase-js (RLS appliqué automatiquement)
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_ANON_KEY!
)

const { data: notes, error } = await supabase
  .from('notes')
  .select('id, content, created_at')
  .order('created_at', { ascending: false })

// 3) Chaînes de connexion avec un client Postgres (tableau officiel "Endpoints and IP versions")
// Direct connection (backend persistant, pg_dump, migration) :
// postgresql://postgres:[YOUR-PASSWORD]@db.[PROJECT-REF].supabase.co:5432/postgres
// Dedicated pooler (mode transaction uniquement, sur les plans payants) :
// postgresql://postgres:[YOUR-PASSWORD]@db.[PROJECT-REF].supabase.co:6543/postgres
// Construction manuelle de la chaîne : copier depuis l'écran Dashboard > Connect (l'hôte du shared pooler ne peut pas être déduit de la région).

Conclusion

Cette décision n'a pas une seule bonne réponse. Si tu es dans une petite équipe et que la vitesse prime, Supabase est le bon choix : auth, storage, realtime et pooler arrivent prêts à l'emploi. Avec une charge prévisible, une contrainte de résidence des données (la Turquie ne figure pas parmi les 17 régions) ou un coût qui grimpe avec le nombre d'utilisateurs, PostgreSQL auto-hébergé l'emporte. Un avertissement : la documentation officielle indique que la sauvegarde/PITR managée est désactivée en self-host — avec le contrôle, tu hérites de la répétition de restauration. Faire une sauvegarde n'est pas le critère ; pouvoir restaurer l'est.

Obtenir une consultation gratuite
FAQ

Questions fréquentes

Comme Supabase utilise du PostgreSQL standard, tu peux exporter avec `pg_dump`/`pg_dumpall` ou via la réplication native Postgres ; la documentation officielle décrit la migration entre projets avec un exemple de script Node.js (auth/storage inclus). Recréer côté self-host les services propres à Supabase comme Auth, Storage et Realtime (en exécutant la stack self-host officielle avec Docker Compose) est un chantier distinct — migrer les données et atteindre la parité de services sont deux étapes différentes.

Articles de blog associés

Voir tous les articles
Toutes les comparaisons