PostgreSQL vs MongoDB
PostgreSQL, le champion open-source des bases de données relationnelles, face à MongoDB, la base de données NoSQL orientée documents et flexible. Comment choisir la bonne base de données selon votre modèle de données ?
Base de données relationnelle open source, exécutée sur ton propre serveur, mûrie depuis 1986
Plateforme backend open source managée, construite sur du vrai PostgreSQL
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.
| Catégorie | Self-hosted PostgreSQL | Supabase |
|---|---|---|
| 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 |
# 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-- 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).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 gratuiteComme 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.