Les projets hébergés sur le plan gratuit de Supabase sont automatiquement mis en pause après 7 jours d’inactivité.

Cette politique peut entraîner des interruptions de service pour les développeurs travaillant sur des projets de test, des POC (Proof of Concept) ou des applications à faible trafic.

Cet article présente une solution technique automatisée utilisant l’extension PostgreSQL pg_cron pour maintenir vos projets Supabase actifs en permanence.

Table des Matières

1. Comprendre la politique de mise en pause Supabase

Règles du plan gratuit (Free Tier)

Supabase applique une politique stricte sur son plan gratuit :

Délai d’inactivité : 7 jours consécutifs sans activité applicative sur la base de données
Action automatique : Mise en pause du projet (« Project Paused »)
Notification : Un email d’avertissement environ une semaine avant la mise en pause, puis un email de confirmation une fois la pause effective
Restauration : Manuelle via le dashboard Supabase, possible pendant 90 jours après la mise en pause
Temps de redémarrage : Environ 30 secondes après la première requête entrante (réveil automatique)

En 2026, le plan Free inclut par ailleurs 500 Mo de base de données, 1 Go de stockage fichiers, 5 Go d’egress, 50 000 utilisateurs actifs mensuels, 500 000 invocations Edge Functions et jusqu’à 2 projets actifs par organisation (source : Supabase Pricing). Il ne comprend aucune sauvegarde automatique ni SLA, ce qui aggrave le risque de perte de données en cas de pause prolongée.

Qu’est-ce qui constitue une « activité » ?

Une activité est considérée comme toute opération effectuée sur la base de données :

Requêtes SELECT, INSERT, UPDATE, DELETE
Connexions à la base de données
Transactions PostgreSQL
Exécution de fonctions stockées

L’accès au dashboard Supabase ou aux APIs REST sans interaction avec la base de données ne compte pas comme activité. C’est la confusion la plus fréquente chez les utilisateurs : consulter régulièrement son dashboard ne suffit pas à empêcher la mise en pause.

2. Impact de la mise en pause automatique

Conséquences techniques

La mise en pause d’un projet Supabase entraîne :

Indisponibilité totale de l’API : Tous les endpoints REST retournent des erreurs de connexion
Échec des webhooks : Les intégrations avec n8n, Zapier ou Make cessent de fonctionner
Perte de connectivité : Les applications front-end ne peuvent plus communiquer avec la base de données
Arrêt des tâches planifiées : Les jobs cron internes cessent de s’exécuter

Cas d’usage affectés

Cette politique impacte particulièrement :

Projets de développement et de test
Applications personnelles à faible trafic
POC (Proof of Concept) et démonstrateurs
Projets en maintenance passive
Side projects développés de manière intermittente

Alternative officielle

Supabase propose le plan Pro à 25 $/mois (incluant un crédit compute de 10 $/mois), qui élimine cette contrainte : un projet sous plan payant n’est jamais mis en pause pour inactivité. Pour les développeurs gérant plusieurs projets de test, cette solution peut représenter un coût mensuel significatif (75 à 100 $ pour 3 à 4 projets).

Ce qui change en 2026

Deux points ont bougé côté Supabase depuis un changement de politique documenté en 2025. D’abord, un projet Free mis en pause reste restaurable pendant 90 jours depuis Supabase Studio (au-delà, il faut passer par le téléchargement des backups disponibles puis une migration manuelle vers un nouveau projet, quand ils existent). Ensuite, Supabase envoie désormais deux emails automatiques au propriétaire du projet : un avertissement environ une semaine avant la pause, puis une confirmation une fois celle-ci effective, ce qui limite les mauvaises surprises par rapport aux versions précédentes de la politique.

Ce délai de 90 jours ne compense pas l’absence de sauvegardes automatiques sur le plan Free : si votre projet reste en pause au-delà, la récupération dépend uniquement des backups déjà disponibles au moment de la pause. Pour un projet que vous comptez garder actif sans passer au plan Pro, le heartbeat pg_cron présenté plus bas reste la solution la plus fiable pour ne jamais atteindre cette situation.

3. Solution technique : Heartbeat avec pg_cron

Architecture de la solution

Cette solution repose sur trois composants natifs de PostgreSQL :

Extension pg_cron : Planificateur de tâches intégré au moteur de base de données
Table keep_alive : Table dédiée à l’enregistrement d’un timestamp d’activité
Transaction quotidienne optimisée : Cycle DELETE + INSERT maintenant une ligne unique

Principe de fonctionnement

Le système exécute automatiquement une transaction PostgreSQL chaque jour à minuit UTC. Cette opération :

Supprime l’unique ligne de la table keep_alive
Insère une nouvelle ligne avec le timestamp actuel
Signale une activité à l’infrastructure Supabase
Évite l’accumulation de données (la table contient toujours une seule ligne)

Avantages de cette approche

Par rapport aux solutions externes (n8n, Zapier) :

Aucune dépendance à un service tiers
Pas de quota de requêtes à surveiller
Pas de risque de défaillance d’un service externe
Aucune gestion de credentials ou d’API keys

Par rapport aux scripts hébergés :

Aucun serveur à maintenir
Aucun frais d’hébergement
Aucune configuration réseau ou firewall

Par rapport à l’intervention manuelle :

Automatisation complète
Aucune charge mentale
Fonctionne 24/7 sans surveillance

Conformité et bonnes pratiques

Cette solution :

Utilise des fonctionnalités natives officiellement supportées par Supabase
N’exploite aucune faille ou comportement non documenté
Génère une charge système négligeable (transaction de quelques millisecondes par jour)
Respecte les conditions d’utilisation de Supabase

4. Guide d’installation étape par étape

Prérequis

Un projet Supabase actif (plan gratuit ou Pro)
Accès au SQL Editor du projet
Aucune compétence PostgreSQL avancée requise

Étape 1 : Accéder au SQL Editor

Connectez-vous à votre dashboard Supabase
Sélectionnez le projet concerné
Naviguez vers SQL Editor dans le menu latéral

Étape 2 : Exécuter le script d’installation

Copiez et exécutez le script suivant dans le SQL Editor :

-- Activation de l'extension pg_cron
CREATE EXTENSION IF NOT EXISTS pg_cron;

-- Création de la table keep_alive
CREATE TABLE IF NOT EXISTS public.keep_alive (
    last_ping timestamptz DEFAULT now()
);

-- Nettoyage d'anciens jobs éventuels (évite les doublons)
SELECT cron.unschedule('prevent_project_pause');

-- Planification du job quotidien à 00:00 UTC
-- Le job supprime puis insère une ligne unique
SELECT cron.schedule(
    'prevent_project_pause',
    '0 0 * * *',
    $$DELETE FROM public.keep_alive; INSERT INTO public.keep_alive DEFAULT VALUES;$$
);

-- Exécution immédiate pour amorçage
DELETE FROM public.keep_alive;
INSERT INTO public.keep_alive DEFAULT VALUES;

Étape 3 : Validation de l’exécution

Après exécution, vous devriez voir :

Message de confirmation de création de l’extension
Message de confirmation de création de la table
Confirmation de la planification du job cron
Une ligne insérée dans la table keep_alive

5. Vérification et diagnostic

Script de vérification

Exécutez ce script pour vérifier le statut du système :

SELECT
    J.jobname AS "Nom du Job",
    CASE
        WHEN J.active IS TRUE THEN '✅ ACTIF'
        ELSE '❌ INACTIF'
    END AS "État Planificateur",
    CASE
        WHEN (SELECT status FROM cron.job_run_details WHERE jobid = J.jobid ORDER BY start_time DESC LIMIT 1) = 'succeeded' 
            THEN '✅ SUCCÈS (Via Cron)'
        WHEN (SELECT last_ping FROM public.keep_alive LIMIT 1) > (now() - interval '5 minutes') 
            THEN '✅ SUCCÈS (Test manuel immédiat OK)'
        ELSE '⚠️ NON DÉTECTÉ'
    END AS "Statut Opérationnel",
    COALESCE(
        (SELECT to_char(last_ping, 'DD/MM/YYYY HH24:MI:SS') FROM public.keep_alive LIMIT 1),
        'Aucune donnée'
    ) AS "Dernier Ping (Table)"
FROM
    cron.job J
WHERE
    J.jobname = 'prevent_project_pause';

Interprétation des résultats

Résultat attendu :

État Planificateur : ✅ ACTIF
Statut Opérationnel : ✅ SUCCÈS (Via Cron) ou ✅ SUCCÈS (Test manuel immédiat OK)
Dernier Ping : Date et heure récentes

En cas de problème :

Si « État Planificateur » est ❌ INACTIF : Réexécutez le script d’installation
Si « Statut Opérationnel » est ⚠️ NON DÉTECTÉ : Vérifiez les permissions de la base de données
Si aucun résultat n’apparaît : Le job n’a pas été créé correctement

Vérification de l’historique d’exécution

Pour consulter l’historique des exécutions du job :

SELECT 
    jobid,
    runid,
    job_pid,
    database,
    username,
    command,
    status,
    return_message,
    start_time,
    end_time
FROM 
    cron.job_run_details
WHERE 
    jobid = (SELECT jobid FROM cron.job WHERE jobname = 'prevent_project_pause')
ORDER BY 
    start_time DESC
LIMIT 10;

6. Désinstallation

Quand désinstaller ?

La désinstallation est recommandée dans les cas suivants :

Migration vers le plan Pro de Supabase
Projet définitivement abandonné
Passage à une solution de maintien d’activité différente

Script de désinstallation

-- Suppression du job cron
SELECT cron.unschedule('prevent_project_pause');

-- Suppression de la table
DROP TABLE IF EXISTS public.keep_alive;

Cette opération est réversible : vous pouvez réinstaller le système à tout moment en réexécutant le script d’installation initial.

7. FAQ (Questions fréquemment posées)

Est-ce que pg_cron est disponible sur le plan gratuit de Supabase ?

Oui, l’extension pg_cron est disponible sur tous les plans Supabase, y compris le plan gratuit (Free Tier).

Cette solution consomme-t-elle beaucoup de ressources ?

Non. La transaction quotidienne prend quelques millisecondes et la table keep_alive ne contient qu’une seule ligne. L’impact sur les performances et le stockage est négligeable.

Est-ce conforme aux conditions d’utilisation de Supabase ?

Oui. Cette solution utilise des fonctionnalités PostgreSQL officiellement supportées par Supabase. Elle génère une activité légitime sur la base de données sans exploiter de faille ou de comportement non documenté.

Que se passe-t-il si le job cron échoue ?

En cas d’échec ponctuel, le système réessaiera le lendemain à minuit. Vous pouvez consulter l’historique d’exécution pour identifier d’éventuels problèmes récurrents.

Puis-je modifier l’horaire d’exécution ?

Oui. Modifiez la ligne contenant '0 0 * * *' dans le script d’installation. Cette expression cron définit l’horaire (minuit UTC par défaut). Consultez la documentation de cron pour d’autres formats horaires.

La solution fonctionne-t-elle pour plusieurs projets ?

Oui, mais vous devez installer le système séparément sur chaque projet Supabase. Chaque projet dispose de sa propre base de données et de son propre planificateur pg_cron. Notez qu’en 2026 le plan Free autorise jusqu’à 2 projets actifs par organisation : si vous en gérez plusieurs, vérifiez que cette limite vous convient avant de multiplier les installations.

Puis-je utiliser cette méthode sur le plan Pro ?

Oui, bien que ce ne soit pas nécessaire puisque le plan Pro n’applique pas de mise en pause automatique. Certains utilisateurs préfèrent néanmoins maintenir ce système par précaution.

Combien de temps ai-je pour restaurer un projet Supabase mis en pause ?

90 jours depuis Supabase Studio, selon la politique en vigueur depuis 2025. Passé ce délai, le projet n’est plus restaurable directement dans l’interface : la récupération dépend uniquement des backups déjà disponibles au moment de la pause, suivis d’une migration manuelle vers un nouveau projet. Sur le plan Free, l’absence de sauvegardes automatiques rend cette situation risquée, d’où l’intérêt du heartbeat pg_cron décrit plus haut pour éviter d’en arriver là.

Comment vérifier que mon projet ne sera plus mis en pause ?

Observez le comportement sur 7-10 jours. Consultez régulièrement le script de vérification pour confirmer que le job s’exécute correctement chaque jour.

Existe-t-il des alternatives à cette solution ?

Oui, plusieurs alternatives existent :

Workflow externe (n8n, Zapier) : Nécessite un service tiers et une surveillance
Script hébergé (cron job serveur) : Nécessite un serveur et une maintenance
Requête API régulière : Nécessite un service externe avec accès réseau
Plan Pro Supabase (25 $/mois) : Solution officielle sans contrainte technique

La solution pg_cron présentée dans cet article offre le meilleur rapport simplicité/fiabilité pour les projets du plan gratuit.

Conclusion

La mise en place d’un système de heartbeat automatique avec pg_cron permet de maintenir vos projets Supabase actifs indéfiniment sur le plan gratuit, sans intervention manuelle ni dépendance externe.

Points clés à retenir :

Installation en 2 minutes via un script SQL
Maintenance : aucune
Consommation de ressources : négligeable
Fiabilité : exécution automatique quotidienne
Conformité : utilisation de fonctionnalités officielles

Cette solution est particulièrement adaptée aux développeurs gérant des projets de test, des POC ou des applications personnelles à faible trafic, permettant de rester sur le plan gratuit sans subir les contraintes de la mise en pause automatique.