Supabase ou PostgreSQL seul sur votre propre serveur

La configuration Docker auto-hébergée de Supabase, version v0.8.3 du 16 octobre 2026, démarre 11 conteneurs. L'un d'eux est PostgreSQL 17. Les dix autres sont une passerelle, la connexion des utilisateurs, une API REST, le stockage de fichiers, le redimensionnement d'images, les mises à jour en direct, les fonctions serveur, un pooler de connexions, une API d'administration de la base de données et le tableau de bord Studio. Sur un serveur x86, les 11 images représentent environ 2,15 Go à télécharger, selon notre addition des tailles x86 indiquées sur Docker Hub pour les tags d'image du fichier compose. L'image officielle de PostgreSQL 17 pèse environ 161 Mo.

La documentation de l'API de Supabase décrit deux façons d'appeler ses API : directly from the browser (two-tier architecture), or as a complement to your own API server (three-tier architecture). Si une application web ou mobile communique avec votre base de données, ces dix services constituent le backend que vous auriez sinon à écrire. Si votre propre serveur fait l'intermédiaire, PostgreSQL est la partie qu'utilise votre application.

Ce que Supabase ajoute à PostgreSQL

Pour chaque tâche ci-dessous, la colonne du milieu indique le service Supabase qui s'en charge, d'après la page d'architecture de Supabase et son README d'auto-hébergement en v0.8.3.

Notre choix pour un cas courant : une application Next.js, React ou mobile encore sans code serveur tire le meilleur parti de Supabase. Sans lui, tout cela serait du code à écrire avant le lancement. Une équipe qui dispose déjà d'un backend Rails, Django ou Express gagne peu aux dix services supplémentaires.

DreamHost propose les deux sous forme de serveurs avec le logiciel préinstallé, l'hébergement VPS Supabase et l'hébergement VPS PostgreSQL, sur les mêmes plans Stack aux mêmes prix. Si vous utilisez actuellement Supabase Cloud et vous demandez si un serveur coûterait moins cher, commencez par ce que coûte Supabase Cloud à mesure que vous grandissez. Si vous hésitez entre un service PostgreSQL géré et PostgreSQL seul sur un serveur, lisez ce que coûte Postgres géré comparé à un serveur.

Ce qui a fonctionné dès le premier jour

Nous avons testé chaque tâche sur Supabase juste après l'installation, sans autre code de notre part que des scripts de test, et les sept ont fonctionné.

• Connecter un utilisateur et obtenir un jeton. Nous avons créé l'utilisateur via l'API d'administration, car la configuration par défaut n'a pas de serveur de messagerie pour les e-mails de confirmation.
• Lire et écrire dans une table via HTTP sous une politique de sécurité au niveau des lignes. L'utilisateur connecté a vu son unique ligne, et une requête sans utilisateur connecté a obtenu 0 ligne.
• Envoyer un fichier et télécharger les mêmes octets. Nous avons utilisé un bucket privé, et le fichier téléchargé était identique octet pour octet.
• Redimensionner une image. Le service imgproxy a transformé un PNG de 800x600 en une image de 200 pixels de large.
• Appeler une fonction serveur. La fonction hello fournie a répondu.
• Recevoir un événement à l'ajout d'une ligne. Un client supabase-js a reçu la nouvelle ligne 283 ms après l'insertion.
• Ouvrir un tableau de bord web. Studio a d'abord demandé ses identifiants.

Sur PostgreSQL 17 seul, nous avons effectué les deux tâches que la base de données assure elle-même. La même politique de sécurité au niveau des lignes a fonctionné en SQL, et LISTEN et NOTIFY ont transmis un événement entre deux sessions SQL. Le reste exige des logiciels en plus de la base de données : une API HTTP, la connexion, le stockage de fichiers, des fonctions serveur, une connexion navigateur pour les mises à jour en direct et un tableau de bord.

Realtime nous a piégés lors du premier essai : le client supabase-js a indiqué s'être abonné au bout de 35 ms, et la ligne insérée juste après n'est jamais arrivée. Lors du second essai, nous avons journalisé les événements système du canal : le client a signalé subscribed à 32 ms, et le message Subscribed to PostgreSQL de Realtime est arrivé environ 2,4 secondes plus tard. Si votre application écrit une ligne juste après l'abonnement, écoutez l'événement system du canal et attendez ce message avant d'insérer.

Ce que chacun exige de votre serveur

Supabase publie les ressources requises par sa stack. PostgreSQL ne le fait pas : nos mesures comblent ce manque. Dans le tableau, Supabase désigne la configuration auto-hébergée v0.8.3 et PostgreSQL désigne PostgreSQL 17 seul.

Les lignes allant de la mémoire au repos aux extensions sont nos propres mesures, effectuées le 19 octobre (VM de 8 Go) et le 20 octobre 2026 (VM de 4 Go), décrites dans la section notre méthode de mesure. Les durées s'entendent avec les images déjà téléchargées. Les décomptes proviennent du fichier compose au tag self-hosted/v0.8.3 de Supabase, les tailles de téléchargement des données de tags de Docker Hub, et les exigences de la documentation de chaque éditeur, toutes consultées le 16 octobre 2026.

Logs & Analytics sont désactivés dans la configuration par défaut de Supabase pour réduire l'empreinte mémoire ; vous les activez avec un fichier de surcharge qui ajoute Logflare et Vector et augmente les besoins de la stack.

Stack 4 atteint le minimum de Supabase. Stack 8 ajoute la RAM et le disque recommandés, mais conserve 2 vCPU. Stack 16 est le plus petit plan qui atteint toutes les valeurs recommandées par Supabase, avec 4 vCPU, 16 Go de RAM et 250 Go de stockage NVMe selon la page VPS Supabase : c'est notre choix pour la production, et Stack 8 convient à une petite application ou à une copie de préproduction.

Notre essai sur 4 Go montre que la stack par défaut tient sur Stack 4 au repos. Les 11 conteneurs ont tourné sans redémarrage, et leur mémoire s'est stabilisée à un peu plus d'un tiers des 3 904 Mio de la VM. Les images occupaient environ 9,7 Go de disque, bien en deçà des 75 Go de Stack 4.

La même stack a utilisé environ moitié plus de mémoire sur la VM de 4 Go que sur celle de 8 Go. Studio, Realtime et le pooler ont augmenté de 16 à 22 %, et cinq petits services ont été multipliés par deux à sept, imgproxy passant d'environ 13 Mio à 94 Mio. Nous n'avons fait qu'un essai de chaque et ne pouvons pas expliquer cet écart : nous prévoirions donc 1 à 1,5 Go pour Supabase au repos, en dimensionnant en plus pour le trafic de votre application.

Pour PostgreSQL seul, nous placerions une base de données de production sur Stack 8, le plan que la page VPS PostgreSQL présente comme Pour les applications en production. Stack 4, présenté comme Pour les applications légères et les projets solo, suffit pour démarrer. Selon la page, passer de Stack 4 à Stack 32 est simple, et votre environnement vous suit. Pour dimensionner le serveur en fonction de tout ce que vous y exécuterez d'autre, consultez le plan VPS dont vous avez besoin.

Ce que PostgreSQL seul vous laisse à faire

Votre backend se charge de ces tâches, et Rails et Django en fournissent une bonne partie. Rails inclut un générateur d'authentification, Active Storage gère les envois de fichiers et les variantes d'images, et Action Cable apporte les WebSockets au navigateur. Django dispose d'un système d'authentification des utilisateurs intégré, et Channels ajoute les WebSockets. Une application Express les ajoute sous forme de bibliothèques, par exemple Socket.IO pour une connexion bidirectionnelle en direct entre le navigateur et votre serveur.

PostgreSQL couvre lui-même une partie de la liste. Ses politiques de sécurité au niveau des lignes limitent, pour chaque utilisateur, les lignes qu'une requête renvoie ou modifie, et les règles d'accès de Supabase sont ces mêmes politiques. LISTEN et NOTIFY envoient un événement à chaque session de base de données à l'écoute, ce qui permet à un worker de votre backend de réagir aux nouvelles lignes. Un navigateur n'ouvre pas de session de base de données : les mises à jour en direct dans le navigateur passent donc par votre propre serveur WebSocket, comme Action Cable, Channels ou Socket.IO. Les extensions comme pgvector et PostGIS s'installent sur notre serveur PostgreSQL grâce à l'accès root complet.

Si c'est l'API automatique qui vous manquerait, vous pouvez exécuter PostgREST seul. C'est le serveur web derrière l'API REST de Supabase, et son README le décrit ainsi : serves a fully RESTful API from any existing PostgreSQL database.

Supabase auto-hébergé au quotidien

La page d'auto-hébergement de Supabase liste ce dont vous vous chargez en l'exécutant vous-même : l'entretien du serveur, la mise à jour du système d'exploitation et des services, la maintenance de Postgres, la haute disponibilité, ainsi que les sauvegardes et la restauration.

• HTTPS. La configuration Docker de Supabase répond en HTTP simple, ce qui suffit sur une machine de test. En production, le guide du proxy de Supabase place Caddy ou Nginx avec Let’s Encrypt devant la passerelle.
• E-mail. Les paramètres Docker par défaut de Supabase activent l'inscription par e-mail avec confirmation et envoient les messages vers un conteneur qui n'existe que dans le fichier de développement de Supabase. Ajoutez votre propre serveur SMTP avant que de vrais utilisateurs s'inscrivent, sinon les e-mails de confirmation et de réinitialisation du mot de passe ne partiront pas.
• Mises à jour. Le guide Docker de Supabase indique qu'un instantané stable est publié environ une fois par mois. Son script de mise à jour fusionne les paramètres de la nouvelle version avec les vôtres. Vous téléchargez ensuite les nouvelles images et recréez les conteneurs. Faites une sauvegarde avant de l'exécuter.
• Projets. Une installation exécute un seul projet. Studio auto-hébergé ne peut pas gérer plusieurs organisations ou projets : une deuxième application nécessite donc sa propre installation.

Le guide d'auto-hébergement détaille les étapes d'installation, et le guide Docker de Supabase sert de référence pour chaque paramètre.

Notre méthode de mesure

DreamHost a fait tourner les deux piles logicielles le 19 octobre 2026 sur une VM de test locale dotée de 2 vCPU et de 7 922 Mio de mémoire : Ubuntu 24.04.4 sur arm64, sous Colima, sur un Mac à puce Apple. Nos offres tournent sur des processeurs x86 AMD EPYC : il ne s'agissait donc pas d'un serveur DreamHost. Comme la taille des images varie selon le processeur, le tableau indique aussi la taille du téléchargement en x86.

Supabase a été lancé depuis son dossier Docker v0.8.3 tel que publié, avec des secrets générés par ses propres scripts de clés. PostgreSQL a été lancé à partir du fichier compose d'exemple de Docker Hub, figé sur postgres:17.11, sans son service Adminer. Chaque valeur de mémoire est la médiane de 12 relevés docker stats, un toutes les 5 secondes, à partir de 10 minutes après le démarrage. Les images avaient été téléchargées avant que nous chronométrions les démarrages.

Le 20 octobre, nous avons de nouveau lancé Supabase sur une deuxième VM dimensionnée comme Stack 4, avec 2 vCPU, 3 904 Mio de mémoire et sans swap, avec les mêmes versions d'Ubuntu et de Docker. Elle utilisait une copie neuve du même dossier v0.8.3, de nouveaux secrets et les mêmes 12 relevés après 10 minutes. Une petite application de test sans rapport, d'environ 180 Mio, tournait aussi sur cette VM. Elle n'est comptée dans aucun des chiffres de Supabase que nous citons.

Nous avons exécuté chaque configuration une seule fois : il n'y a donc pas de dispersion à signaler. Les tests portent sur une pile logicielle au repos et sur ce qui fonctionne dès l'installation. Ils ne couvrent ni une application sous charge ni une semaine de fonctionnement, et nous n'avons pas essayé avec Logs & Analytics activé.

FAQ : Supabase ou PostgreSQL seul