J'ai aidé trois entreprises à migrer hors de Bubble au cours de la dernière année seulement. Chacune a commencé de la même façon : quelqu'un de l'équipe a ouvert sa facture mensuelle, a vu un chiffre qui lui a donné des sueurs froides, et s'est mis à chercher sur Google « alternative à Bubble ». Si c'est votre cas en ce moment, respirez. Vous n'êtes pas seul, et c'est en fait un problème qui peut être résolu.

Bubble est vraiment génial pour mettre un MVP en place. Je l'ai recommandé à des fondateurs en phase de démarrage plus de fois que je ne peux le compter. Mais je constate un schéma répétitif : le produit grandit, l'équipe grandit, la base d'utilisateurs grandit -- et soudainement Bubble ne grandit pas avec vous. Il vous retient. Le modèle de tarification par workflow unit (WU) qui semblait acceptable avec 1 000 utilisateurs devient un problème sérieux avec 50 000. L'éditeur visuel qui semblait libérateur commence à ressembler à une cage quand vous avez besoin d'une logique personnalisée. Les temps de chargement des pages qui étaient « acceptables » deviennent embarrassants.

Cet article est le guide de migration que j'aurais aimé avoir la première fois que j'ai fait ça. Nous allons discuter de pourquoi les équipes dépassent Bubble, à quoi ressemblent les vrais coûts en 2026, et comment réellement exécuter une migration vers Next.js et Supabase sans brûler votre entreprise.

Table des matières

Outgrown Bubble? How to Migrate to Next.js and Supabase in 2026

Pourquoi les équipes dépassent Bubble

Soyons spécifiques sur ce que « dépasser » signifie réellement, car ce n'est pas une seule chose. C'est généralement une combinaison de plusieurs douleurs qui se renforcent mutuellement.

Les limites de performance

Les applications Bubble s'exécutent sur une infrastructure partagée. Votre application partage les ressources de calcul avec d'autres applications Bubble. Quand votre application reçoit des pics de trafic, vous ne pouvez pas simplement lancer plus d'instances -- vous êtes à la merci de Bubble. J'ai vu des applications Bubble avec 500+ utilisateurs simultanés atteindre des temps de réponse de 3-5 secondes pour des requêtes basiques de base de données. Ce n'est pas un bug ; c'est l'architecture.

Les pages Bubble sont aussi lourdes. Une page Bubble typique expédie 2-4 MB de JavaScript au client. Comparez ça à une page Next.js bien construite qui pourrait expédier 200-400 KB. Vos utilisateurs sentent cette différence, particulièrement sur mobile.

Le problème des plugins

L'écosystème des plugins de Bubble est à la fois sa force et son talon d'Achille. Vous installerez des plugins pour l'intégration Stripe, pour la génération de PDF, pour l'envoi d'emails -- et chacun est maintenu par un développeur tiers aléatoire qui pourrait l'abandonner mardi prochain. J'ai vu des applications en production se casser parce qu'un auteur de plugin a poussé une mauvaise mise à jour. Vous n'avez aucun contrôle.

Le verrouillage des fournisseurs est réel

Votre application entière -- la logique, les données, l'interface utilisateur -- vit dans le système propriétaire de Bubble. Il n'y a pas de bouton « exporter mon application ». Vos workflows ne sont pas du code ; ce sont des configurations visuelles stockées au format de Bubble. Si Bubble change sa tarification (ce qu'ils ont fait, plusieurs fois), vous payez plus ou vous recommencez. C'est une position de négociation terrible pour n'importe quel entreprise.

Les problèmes d'échelle de l'équipe

Essayez d'embaucher un « développeur Bubble » en 2026. Le pool de talents est minuscule comparé aux développeurs React/Next.js. Le contrôle de version dans Bubble est primitif comparé à Git. Avoir plusieurs développeurs travaillant sur la même application Bubble simultanément est un exercice de frustration. Il n'y a pas de vrai processus de révision de code, pas de stratégie de branchement, pas de pipeline CI/CD.

La réalité de la tarification de Bubble en 2026

Bubble est passé à la tarification par workflow unit (WU) en 2023, et ils l'ont ajustée plusieurs fois depuis. Dès le début de 2026, voici à quoi vous faites face :

Plan Coût mensuel Workflow Units Taux WU côté serveur Taux WU côté client
Gratuit $0 Limité (tests uniquement) S/O S/O
Starter $32/mois 10 000 WU 1 WU par action 0,2 WU par action
Growth $129/mois 50 000 WU 1 WU par action 0,2 WU par action
Team $349/mois 150 000 WU 1 WU par action 0,2 WU par action
Enterprise Personnalisé Personnalisé Personnalisé Personnalisé
Dépassement Par WU — $0,003/WU $0,003/WU

Voici où ça devient moche. Une application SaaS modérément complexe avec 10 000 utilisateurs actifs peut facilement brûler 500 000 à 1 000 000 de WU par mois. C'est 1 050 $ à 2 550 $ de frais de dépassement en plus du plan Team. J'ai vu des entreprises payer 3 000 $ à 8 000 $/mois sur Bubble pour des applications qui pourraient fonctionner avec 50 $ à 200 $/mois d'infrastructure cloud.

Le modèle WU est particulièrement punitif car il vous facture pour des choses qui seraient essentiellement gratuites dans une pile personnalisée. Chercher dans votre base de données ? Ça coûte des WU. Planifier un workflow récurrent ? Des WU. Envoyer une notification ? Des WU. Chaque appel API, chaque vérification conditionnelle côté serveur -- tout s'additionne.

Et voici la partie qui fait vraiment mal : la tarification de Bubble n'a bougé que dans une direction. Le modèle WU a remplacé l'ancienne tarification basée sur la capacité, et de nombreux utilisateurs ont vu leurs factures multiplier par 2 à 5 du jour au lendemain. Il n'y a aucune garantie que ça ne se reproduise pas.

Pourquoi Next.js + Supabase est le bon choix

J'ai évalué des dizaines de stratégies de sortie de Bubble au fil des années. Rails, Django, Laravel, React simple avec Firebase -- ce sont tous des choix valides. Mais pour les équipes venant de Bubble spécifiquement, la combinaison Next.js + Supabase atteint un sweet spot qui est difficile à battre.

Next.js vous donne ce que Bubble ne peut pas

Next.js 15 (la version stable actuelle en 2026) vous donne le rendu côté serveur, la génération statique, les routes API, les middlewares, et les fonctions edge tout dans un seul framework. Vos pages se chargent vite car vous expédiez uniquement le JavaScript dont cette page a besoin. L'App Router vous donne des layouts, des états de chargement, et des error boundaries qui prendraient des douzaines de workflows Bubble pour approximer.

Plus important encore, c'est React. L'écosystème React est énorme. Besoin d'un sélecteur de date ? Il y a 50 options éprouvées au combat. Besoin de graphiques ? Recharts, Visx, Nivo -- choisissez votre poison. Besoin d'auth ? NextAuth.js (maintenant Auth.js) ou Supabase Auth. Vous n'êtes jamais bloqué en attendant qu'un développeur de plugin corrige un bug.

Si vous envisagez cette voie, notre équipe de développement Next.js a migré plusieurs applications Bubble et peut partager les détails de ce à quoi ressemble le processus.

Supabase remplace le backend de Bubble

Supabase est la chose la plus proche d'un « remplacement de backend Bubble » qui existe. Voici pourquoi :

  • Base de données PostgreSQL -- une vraie base de données relationnelle interrogeable et indexable au lieu de la structure de données bizarre de Bubble
  • Row Level Security (RLS) -- définissez qui peut lire/écrire quelles données au niveau de la base de données
  • Auth intégré -- email/mot de passe, liens magiques, fournisseurs OAuth, tout géré
  • Abonnements en temps réel -- mises à jour de données en direct sans sondage
  • Stockage -- téléchargements de fichiers avec livraison CDN
  • Fonctions Edge -- fonctions serverless pour logique personnalisée

La tarification de Supabase en 2026 est dramatiquement moins chère que Bubble à grande échelle :

Bubble (Growth) Supabase (Pro) + Vercel (Pro)
Coût de base mensuel $129 $25 + $20 = $45
À 10K utilisateurs $349+ (dépassement probable) ~$75-150 (avec utilisation)
À 50K utilisateurs $2 000-5 000+ ~$200-500
À 100K utilisateurs $5 000-12 000+ ~$400-1 200
Accès à la base de données Requêtes propriétaires PostgreSQL complet
Code personnalisé Très limité Illimité

Ces chiffres ne sont pas théoriques. Ils sont basés sur des factures réelles que j'ai vues d'entreprises avec lesquelles j'ai travaillé.

Outgrown Bubble? How to Migrate to Next.js and Supabase in 2026 - architecture

Comparaison architecturale : Bubble vs Next.js + Supabase

Mappons les concepts de Bubble à la nouvelle pile pour que vous puissiez voir où tout va :

Concept Bubble Équivalent Next.js + Supabase
Pages Pages/routes Next.js (App Router)
Éléments réutilisables Composants React
Éléments visuels JSX + Tailwind CSS / bibliothèques de composants
Workflows Routes API, Server Actions, Fonctions Edge
Database Things Tables PostgreSQL
Types de données et champs Colonnes de table avec types appropriés
Règles de confidentialité Supabase Row Level Security (RLS)
Workflows backend Fonctions Supabase Edge ou cron
API Connector Appels natifs fetch/axios
Plugins Paquets npm
Auth utilisateur Supabase Auth ou Auth.js
Téléchargements de fichiers Supabase Storage
Planification pg_cron ou externe (Inngest, Trigger.dev)

Le manuel de migration

N'essayez pas de tout reconstruire en une seule fois. J'ai vu ça échouer spectaculairement. Voici l'approche en phases qui fonctionne réellement.

Phase 1 : Audit et planification (1-2 semaines)

Avant d'écrire une seule ligne de code, documentez tout ce que fait votre application Bubble. Je veux dire tout :

  1. Mappez chaque page -- captures d'écran, flux d'utilisateurs, quelles données chaque page lit/écrit
  2. Cataloguez tous les workflows -- côté serveur et côté client, ce qui les déclenche, ce qu'ils font
  3. Documentez le modèle de données -- chaque type de données, chaque champ, chaque relation
  4. Listez toutes les intégrations -- Stripe, SendGrid, Twilio, n'importe quels plugins que vous utilisez
  5. Identifiez ce à couper -- Je parie qu'il y a des fonctionnalités que personne n'utilise. Ne migrez pas de poids mort.

Phase 2 : Construire les fondations (2-3 semaines)

Lancez la nouvelle pile :

npx create-next-app@latest my-app --typescript --tailwind --app
cd my-app
npm install @supabase/supabase-js @supabase/ssr

Configurez votre projet Supabase, configurez l'auth, créez votre schéma de base de données. C'est là que vous avez la chance de corriger toutes les erreurs de modélisation de données que vous avez commises dans Bubble. Profitez des vraies clés étrangères, des index et des types de données appropriés.

Phase 3 : Construire les fonctionnalités principales (4-8 semaines)

Commencez par les fonctionnalités qui reçoivent le plus de trafic. Construisez-les correctement en Next.js. N'essayez pas de répliquer exactement l'interface utilisateur de Bubble -- profitez de cette occasion pour améliorer l'UX.

Phase 4 : Migrer les données et les utilisateurs (1-2 semaines)

C'est la partie effrayante, et elle mérite sa propre section.

Phase 5 : Basculer (1 semaine)

Exécutez les deux systèmes en parallèle, vérifiez que tout fonctionne, puis changez le DNS. Gardez l'application Bubble en fonctionnement en mode lecture seule pendant quelques semaines comme filet de sécurité.

Migration des données : sortir de la base de données de Bubble

Bubble vous permet d'exporter vos données sous forme de fichiers CSV. C'est votre point de départ, mais ce n'est pas aussi propre que vous l'espéreriez.

# Exemple de script Python pour transformer les exports CSV de Bubble
import csv
import json
from supabase import create_client

supabase = create_client(SUPABASE_URL, SUPABASE_KEY)

with open('bubble_users_export.csv', 'r') as f:
    reader = csv.DictReader(f)
    for row in reader:
        # Bubble exporte les dates dans un format bizarre
        created = convert_bubble_date(row['Created Date'])
        
        # Bubble utilise des ID uniques qui ressemblent à « 1677234567890x123456789 »
        # Vous voudrez les mapper en UUIDs
        user_data = {
            'legacy_bubble_id': row['unique id'],
            'email': row['email'],
            'name': row['name_text'],
            'created_at': created,
            # Mappez tous vos champs personnalisés
        }
        
        supabase.table('users').insert(user_data).execute()

Les pièges clés avec les exports de données Bubble :

  • Les relations sont stockées comme des ID Bubble -- vous devez construire une table de mapping pour convertir ceux-ci en vos nouvelles clés étrangères
  • Les champs de fichiers s'exportent comme des URLs Bubble CDN -- vous devez télécharger ces fichiers et les re-télécharger vers Supabase Storage avant que l'application Bubble se déconnecte
  • Les champs de liste s'exportent comme des ID Bubble séparés par des virgules -- ce deviennent des tables de jonction appropriées
  • Les formats de date sont incohérents -- testez votre analyse de dates très soigneusement

Pour l'API de données Bubble, vous pouvez également extraire les données par programmation, ce qui est parfois plus facile que les exports CSV pour les grands ensembles de données :

// Récupération des données de l'API de données de Bubble
const fetchBubbleData = async (type, cursor = 0) => {
  const response = await fetch(
    `https://yourapp.bubbleapps.io/api/1.1/obj/${type}?cursor=${cursor}&limit=100`,
    {
      headers: {
        'Authorization': `Bearer ${BUBBLE_API_KEY}`
      }
    }
  );
  return response.json();
};

Reconstruire votre frontend en Next.js

L'éditeur visuel de Bubble se mappe étonnamment bien à l'architecture basée sur les composants une fois que vous voyez le modèle. Un « Élément réutilisable » de Bubble est littéralement un composant React. Un « Groupe » de Bubble est un <div> avec les classes Tailwind.

Voici un modèle que j'utilise pour les pages qui étaient chargées de données dans Bubble :

// app/dashboard/page.tsx
import { createClient } from '@/lib/supabase/server';
import { DashboardStats } from '@/components/dashboard-stats';
import { RecentActivity } from '@/components/recent-activity';

export default async function DashboardPage() {
  const supabase = await createClient();
  
  const { data: stats } = await supabase
    .from('user_stats')
    .select('*')
    .single();
  
  const { data: activity } = await supabase
    .from('activity_log')
    .select('*, project:projects(name)')
    .order('created_at', { ascending: false })
    .limit(20);

  return (
    <div className="max-w-7xl mx-auto px-4 py-8">
      <h1 className="text-3xl font-bold mb-8">Tableau de bord</h1>
      <DashboardStats stats={stats} />
      <RecentActivity items={activity} />
    </div>
  );
}

Remarquez comment la récupération des données se passe côté serveur. Pas de spinners de chargement, pas de requêtes en cascade. La page arrive complètement rendue. Ça seul rend l'application se sentir dramatiquement plus rapide que la version Bubble.

Pour les bibliothèques de composants, j'ai eu d'excellents résultats avec shadcn/ui. Elle vous donne des composants polis et accessibles que vous possédez (ils sont copiés dans votre codebase, pas importés d'un paquet). Combiné avec Tailwind CSS, vous pouvez reconstruire rapidement les interfaces utilisateur de Bubble et elles seront plus réactives et performantes.

Configurer Supabase comme backend

La Row Level Security de Supabase est votre remplacement pour les Règles de confidentialité de Bubble, et honnêtement, c'est bien plus puissant :

-- Permettez aux utilisateurs de voir uniquement leurs propres données
CREATE POLICY "Users can view own data"
  ON user_profiles FOR SELECT
  USING (auth.uid() = user_id);

-- Permettez aux utilisateurs de mettre à jour leur propre profil
CREATE POLICY "Users can update own profile"
  ON user_profiles FOR UPDATE
  USING (auth.uid() = user_id);

-- Permettez aux admins de voir tout
CREATE POLICY "Admins can view all"
  ON user_profiles FOR SELECT
  USING (
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE user_id = auth.uid()
      AND role = 'admin'
    )
  );

Pour les workflows backend (les choses qui s'exécutaient selon un calendrier dans Bubble), les Fonctions Edge Supabase avec pg_cron fonctionnent bien pour la plupart des cas d'utilisation. Pour la planification de tâches plus complexe, Trigger.dev ou Inngest sont d'excellents choix qui s'intègrent naturellement à Next.js.

Authentification et migration des utilisateurs

C'est la partie la plus délicate de toute la migration. Vos utilisateurs ont des mots de passe stockés dans Bubble, et vous ne pouvez pas exporter les hachages de mots de passe. Vous avez deux options :

  1. Forcer la réinitialisation du mot de passe -- Envoyez à tous les utilisateurs un email « nous avons amélioré notre plateforme » avec un lien de réinitialisation de mot de passe. Simple mais crée une friction.
  2. Migration paresseuse -- Configurez un flux d'authentification personnalisé qui, à la première connexion, essaie de s'authentifier contre l'API de Bubble. Si réussi, créez l'utilisateur dans Supabase avec le mot de passe qu'il vient d'entrer.

L'option 2 est plus de travail mais une bien meilleure expérience utilisateur. Voici la forme générale :

// app/api/auth/migrate-login/route.ts
export async function POST(request: Request) {
  const { email, password } = await request.json();
  
  // Essayez d'abord Supabase
  const { data, error } = await supabase.auth.signInWithPassword({
    email, password
  });
  
  if (data.user) return Response.json({ success: true });
  
  // Si pas dans Supabase, essayez Bubble
  const bubbleAuth = await authenticateWithBubble(email, password);
  
  if (bubbleAuth.success) {
    // Créez un utilisateur dans Supabase avec le même mot de passe
    const { data: newUser } = await supabase.auth.admin.createUser({
      email,
      password,
      email_confirm: true,
    });
    
    // Migrez les données de leur profil
    await migrateUserProfile(bubbleAuth.userId, newUser.user.id);
    
    // Connectez-les
    return Response.json({ success: true });
  }
  
  return Response.json({ error: 'Invalid credentials' }, { status: 401 });
}

Performances et coûts après la migration

Voici les chiffres réels d'une application de gestion de projet que j'ai aidée à migrer fin 2025 :

Métrique Sur Bubble Après migration
Temps de chargement moyen des pages 3,8 s 0,9 s
Temps jusqu'à l'interactivité 5,2 s 1,4 s
Performance Lighthouse 38 92
Coût mensuel de l'infrastructure $4 200 $187
Utilisateurs actifs mensuels 12 000 12 000
Temps de réponse API (p95) 1 800 ms 180 ms
Disponibilité (moyenne 3 mois) 99,2 % 99,97 %

La réduction des coûts seule justifiait la migration en deux mois. Les améliorations de performances ont réduit la rétention par un estimé 15 % au cours du trimestre suivant.

Si vous regardez ces chiffres et pensez « je veux ça mais je n'ai pas l'équipe de dev pour le faire », c'est exactement le type de projet que nous gérons. Consultez notre travail de développement de CMS headless et d'applications ou contactez-nous pour une évaluation de migration.

Les pièges courants et comment les éviter

Essayer de répliquer Bubble exactement

N'essayez pas. La façon de faire de Bubble est souvent la pire façon de le faire dans une pile basée sur le code. Utilisez la migration comme une chance de repenser les flux d'utilisateurs et l'architecture des données.

Sous-estimer la migration des données

Budgétisez le double du temps que vous pensez avoir besoin pour la migration des données. Les exports de données Bubble auront des cas limites qui vous surprendront. Des valeurs nulles là où vous ne les attendiez pas. Des enregistrements dupliqués. Des relations orphelines.

Oublier le stockage des fichiers

Bubble héberge vos fichiers téléchargés sur leur CDN. Quand vous annulez votre plan Bubble, ces URLs meurent. Assurez-vous que chaque fichier est téléchargé et re-téléchargé vers Supabase Storage avant de basculer.

Ne pas configurer la surveillance au début

Dans Bubble, vous ne pensez pas à la surveillance car vous ne pouvez pas vraiment faire grand-chose à propos des problèmes de toute façon. Dans votre nouvelle pile, configurez Sentry pour le suivi des erreurs et Vercel Analytics (ou Plausible/PostHog) pour la surveillance des performances dès le début.

Allez-y seul quand vous ne devriez pas

Si votre application Bubble est complexe et critique pour les revenus, envisagez sérieusement d'obtenir de l'aide d'une équipe qui a déjà fait ça. Le coût d'une migration ratée -- perte de données, temps d'arrêt, rétention d'utilisateurs -- dépasse largement le coût de l'aide professionnelle. Notre page de tarification a des détails sur à quoi ressemblent les engagements.

FAQ

Combien de temps faut-il pour migrer de Bubble à Next.js et Supabase ?

Pour une application SaaS typique avec 10-30 pages et une complexité modérée, comptez 8-16 semaines pour une migration complète. Les applications simples (page d'accueil + tableau de bord + quelques fonctionnalités CRUD) peuvent être faites en 4-6 semaines. Les applications complexes avec beaucoup d'intégrations, de logique personnalisée, et de grands ensembles de données peuvent prendre 16-24 semaines. La migration des données et la transition de l'auth utilisateur sont généralement ce qui prend plus de temps que prévu.

Puis-je migrer de Bubble progressivement, ou est-ce que ça doit être tout en une seule fois ?

Vous pouvez absolument le faire progressivement. Une approche courante est de construire la nouvelle application Next.js aux côtés de l'application Bubble, migrer les fonctionnalités une à la fois, et utiliser le routage des sous-domaines pour envoyer les utilisateurs à la bonne version. Par exemple, votre nouveau tableau de bord vit à app.yoursite.com tandis que les fonctionnalités héritées s'exécutent toujours sur Bubble. Sachez simplement que maintenir deux systèmes simultanément a ses propres coûts.

Qu'en est-il des alternatives à Bubble comme FlutterFlow, WeWeb ou Xano -- devrais-je considérer ceux-ci à la place ?

Si votre principal problème est la tarification de Bubble mais que vous voulez toujours une approche sans code/peu de code, des outils comme WeWeb (frontend) + Xano (backend) peuvent fonctionner. Mais vous échangez un verrouillage de fournisseur pour un autre. Si vous dépassez Bubble à cause des performances, de la scalabilité ou de la taille de l'équipe, vous dépasserez finalement aussi ces outils. Passer à une pile basée sur le code comme Next.js + Supabase est un investissement unique qui se met à l'échelle indéfiniment.

Combien coûte-t-il de lancer une application Next.js + Supabase par rapport à Bubble ?

Pour la plupart des applications SaaS, vous regardez 45-200 $/mois sur Vercel + Supabase pour ce qui coûterait 349-5 000+ $/mois sur Bubble. Supabase Pro coûte 25 $/mois, Vercel Pro coûte 20 $/mois. À grande échelle, vos coûts croissent beaucoup plus lentement car vous payez pour les ressources de calcul réelles plutôt que pour les workflow units. Une règle générale approximative : comptez sur payer 5-20 % de ce que vous payiez sur Bubble.

Ma SEO sera-t-elle affectée par la migration ?

Elle peut s'améliorer considérablement. Les applications Bubble sont rendues côté client et lentes, ce qui nuit aux scores Core Web Vitals. Next.js supporte le rendu côté serveur et la génération statique, ce qui signifie des chargements de pages plus rapides et une meilleure crawlabilité. Assurez-vous simplement de configurer les redirections 301 appropriées depuis vos anciennes URLs Bubble vers les nouvelles routes Next.js, et vous devriez voir des améliorations de SEO dans quelques semaines.

Dois-je connaître PostgreSQL pour utiliser Supabase ?

Les connaissances SQL de base aident beaucoup, mais Supabase fournit un éditeur de table visuel et une bibliothèque client JavaScript qui abstraits la plupart des requêtes. Cela dit, comprendre SQL vous rendra dramatiquement plus efficace. Pour les requêtes complexes, les rapports et l'optimisation des performances, les connaissances SQL sont essentielles. Si votre équipe n'a pas d'expérience SQL, c'est le bon moment pour investir en l'apprendre -- c'est une compétence qui rapporte les dividendes à jamais.

Que se passe-t-il avec les intégrations d'API de mon application Bubble lors de la migration ?

Vous devrez recréer chaque intégration dans votre application Next.js. La bonne nouvelle est que c'est généralement beaucoup plus facile avec le code qu'avec le plugin API Connector de Bubble. Une intégration Stripe qui nécessitait un plugin et 15 workflows dans Bubble pourrait être 50 lignes de code avec le SDK Stripe Node.js. Faites une liste complète de chaque service externe avec lequel votre application Bubble communique et traitez-les un à la fois.

Puis-je utiliser le tier gratuit de Supabase pour la production ?

Le tier gratuit de Supabase en 2026 vous donne 500 MB de stockage de base de données, 1 GB de stockage de fichiers, et 50 000 utilisateurs actifs mensuels sur l'auth. Pour les produits en phase très précoce, cela peut fonctionner. Mais pour n'importe quelle application production sérieuse, vous voudrez le plan Pro à 25 $/mois pour de meilleures performances, des sauvegardes quotidiennes, et aucune pause du projet après l'inactivité. C'est toujours absurdement bon marché comparé à Bubble.