Migrer de Bubble vers Next.js + Supabase en 2026
Votre facture mensuelle arrive et le chiffre vous gèle -- 847 $ en unités de workflow, encore une fois. Vous ouvrez un nouvel onglet et tapez « Bubble alternative » dans la barre de recherche. Trois fondateurs ont fait exactement cela avant de nous appeler l'année dernière. Chacun pensait s'être enfermé dans une impasse. Ils ne l'avaient pas fait. Ce qu'ils avaient réellement fait, c'était valider l'adéquation produit-marché assez fortement pour que la tarification à l'usage de Bubble ne puisse pas évoluer avec eux. La migration vers Next.js et Supabase a pris entre quatre et neuf semaines, selon la quantité de logique personnalisée vivant dans leurs workflows. L'un a économisé 640 $ par mois dès le deuxième mois. Un autre a réduit le temps de chargement de 3,2 secondes à 680 millisecondes et a vu sa conversion d'inscription grimper de onze points. Si votre application Bubble fonctionne mais que l'économie des unités ne fonctionne pas, vous allez voir exactement comment la migration se décompose -- avec du vrai code, de vrais chronologies, et les trois décisions qui déterminent si vous lancez en quatre semaines ou quatre mois.
Bubble est véritablement excellent pour lancer un MVP. Je l'ai recommandé à des fondateurs en phase de démarrage plus de fois que je ne peux les compter. Mais il y a un schéma que je vois continuellement : le produit grandit, l'équipe grandit, la base d'utilisateurs grandit -- et soudain Bubble ne grandit pas avec vous. Il vous retient. Le modèle de tarification des unités de workflow (UW) qui semblait acceptable à 1 000 utilisateurs devient un problème sérieux à 50 000. L'éditeur visuel qui semblait libérateur commence à sembler une cage quand vous avez besoin de 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 cela. Nous allons parler de pourquoi les équipes dépassent Bubble, à quoi ressemblent les vrais coûts en 2026, et comment exécuter réellement une migration vers Next.js et Supabase sans brûler votre entreprise.
Table des matières
- Pourquoi les équipes dépassent Bubble
- La réalité de la tarification Bubble en 2026
- Pourquoi Next.js + Supabase est le bon choix
- Comparaison architecturale : Bubble vs Next.js + Supabase
- Le guide de migration
- Migration des données : sortir de la base de données Bubble
- Reconstruire votre frontend dans Next.js
- Configurer Supabase comme votre backend
- Authentification et migration des utilisateurs
- Performance et coûts après la migration
- Pièges courants et comment les éviter
- FAQ

Pourquoi les équipes dépassent Bubble
Soyons précis sur ce que « dépasser » signifie réellement, parce que ce n'est pas une seule chose. C'est généralement une combinaison de plusieurs points de douleur qui se renforcent mutuellement.
Murs 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 faire tourner 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 les requêtes de base de données basiques. Ce n'est pas un bug ; c'est l'architecture.
Les pages Bubble sont aussi lourdes. Une page Bubble typique envoie 2-4 Mo de JavaScript au client. Comparez cela à une page Next.js bien construite qui pourrait envoyer 200-400 Ko. 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 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 de production casser parce qu'un auteur de plugin a poussé une mauvaise mise à jour. Vous n'avez aucun contrôle.
L'enfermement propriétaire est réel
Toute votre application -- la logique, les données, l'interface utilisateur -- vit à l'intérieur du 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 Bubble. Si Bubble change leur tarification (ce qu'ils ont fait, plusieurs fois), vous payez ou recommencez. C'est une position de négociation terrible pour toute entreprise.
Problèmes d'évolution de l'équipe
Essayez d'embaucher un « développeur Bubble » en 2026. Le bassin de talents est minuscule comparé aux développeurs React/Next.js. Le contrôle de version dans Bubble est primitif par rapport à Git. Faire travailler plusieurs développeurs sur la même application Bubble simultanément est un exercice de frustration. Il n'y a pas de vrai processus d'examen du code, pas de stratégie de branchement, pas de pipeline CI/CD.
La réalité de la tarification Bubble en 2026
Bubble est passé à la tarification par unités de workflow (UW) en 2023, et ils l'ont ajustée plusieurs fois depuis. Dès début 2026, voici à quoi vous avez affaire :
| Plan | Coût mensuel | Unités de workflow | Taux UW côté serveur | Taux UW côté client |
|---|---|---|---|---|
| Gratuit | 0 $ | Limité (test seulement) | N/A | N/A |
| Starter | 32 $ | 10 000 UW | 1 UW par action | 0,2 UW par action |
| Growth | 129 $ | 50 000 UW | 1 UW par action | 0,2 UW par action |
| Team | 349 $ | 150 000 UW | 1 UW par action | 0,2 UW par action |
| Enterprise | Personnalisé | Personnalisé | Personnalisé | Personnalisé |
| Dépassement | Par UW | — | 0,003 $ par UW | 0,003 $ par UW |
C'est ici que ça devient moche. Une application SaaS modérément complexe avec 10 000 utilisateurs actifs peut facilement consommer 500 000-1 000 000 UW par mois. C'est 1 050-2 550 $ en frais de dépassement en plus du plan Team. J'ai vu des entreprises payer 3 000-8 000 $ par mois sur Bubble pour des applications qui pourraient s'exécuter sur 50-200 $ par mois d'infrastructure cloud.
Le modèle UW est particulièrement punitif parce qu'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 UW. Planifier un workflow récurrent ? Des UW. Envoyer une notification ? Des UW. Chaque appel API, chaque vérification conditionnelle côté serveur -- tout s'ajoute.
Et voici la partie qui fait vraiment mal : la tarification Bubble n'a bougé que dans une direction. Le modèle UW a remplacé l'ancienne tarification basée sur la capacité, et de nombreux utilisateurs ont vu leurs factures augmenter 2-5 fois du jour au lendemain. Il n'y a aucune garantie que cela 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 valables. Mais pour les équipes venant spécifiquement de Bubble, la combinaison Next.js + Supabase atteint un sweet spot 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 rapidement parce que vous ne lancez que le JavaScript que cette page a réellement besoin. L'App Router vous donne les layouts, les états de chargement, et les error boundaries qui prendraient des dizaines de workflows Bubble pour se rapprocher.
Plus important encore, c'est React. L'écosystème React est énorme. Vous avez besoin d'un sélecteur de date ? Il y a 50 options battle-tested. Vous avez besoin de graphiques ? Recharts, Visx, Nivo -- choisissez votre poison. Vous avez besoin d'auth ? NextAuth.js (maintenant Auth.js) ou Supabase Auth. Vous ne serez 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 des détails spécifiques sur à quoi ressemble le processus.
Supabase remplace le backend 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, indexable au lieu de la structure de données bizarre de Bubble
- Row Level Security (RLS) -- définir 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 temps réel -- mises à jour de données en direct sans polling
- Stockage -- téléchargements de fichiers avec livraison CDN
- Edge Functions -- fonctions sans serveur pour la logique personnalisée
La tarification de Supabase en 2026 est dramatiquement moins chère que Bubble à l'échelle :
| Bubble (Growth) | Supabase (Pro) + Vercel (Pro) | |
|---|---|---|
| Coût mensuel de base | 129 $ | 25 $ + 20 $ = 45 $ |
| À 10 000 utilisateurs | 349 $ + (dépassement probable) | ~75-150 $ (avec utilisation) |
| À 50 000 utilisateurs | 2 000-5 000 $ + | ~200-500 $ |
| À 100 000 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 de vraies factures que j'ai vues d'entreprises avec lesquelles j'ai travaillé.

Comparaison architecturale : Bubble vs Next.js + Supabase
Cartographions 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, Edge Functions |
| Database Things | Tables PostgreSQL |
| Types et champs de données | Colonnes de table avec types appropriés |
| Règles de confidentialité | Supabase Row Level Security (RLS) |
| Workflows backend | Supabase Edge Functions ou tâches cron |
| API Connector | Appels fetch/axios natifs |
| 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 guide de migration
N'essayez pas de tout reconstruire à la fois. J'ai vu cela échouer spectaculairement. Voici l'approche par 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 votre application Bubble fait. Je veux dire absolument tout :
- Cartographiez chaque page -- captures d'écran, flux utilisateur, quelles données chaque page lit/écrit
- Cataloguez tous les workflows -- côté serveur et côté client, ce qui les déclenche, ce qu'ils font
- Documentez le modèle de données -- chaque type de données, chaque champ, chaque relation
- Listez toutes les intégrations -- Stripe, SendGrid, Twilio, tous les plugins que vous utilisez
- Identifiez ce à couper -- Je garantis qu'il y a des fonctionnalités que personne n'utilise. Ne migrez pas du poids mort.
Phase 2 : Construire la fondation (2-3 semaines)
Mettez en place la nouvelle pile :
npx create-next-app@latest my-app --typescript --tailwind --app
cd my-app
npm install @supabase/supabase-js @supabase/ssr
Configurer votre projet Supabase, configurer l'authentification, créer votre schéma de base de données. C'est ici que vous pouvez corriger tous 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 de base (4-8 semaines)
Commencez par les fonctionnalités qui reçoivent le plus de trafic. Construisez-les correctement dans Next.js. N'essayez pas de reproduire l'interface utilisateur exacte de Bubble -- profitez-en 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écuter les deux systèmes en parallèle, vérifier que tout fonctionne, puis basculer le DNS. Gardez l'application Bubble en mode lecture seule pendant quelques semaines comme filet de sécurité.
Migration des données : sortir de la base de données Bubble
Bubble vous permet d'exporter vos données en tant que 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 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 IDs uniques qui ressemblent à "1677234567890x123456789"
# Vous voudrez mapper ceux-ci à des UUIDs
user_data = {
'legacy_bubble_id': row['unique id'],
'email': row['email'],
'name': row['name_text'],
'created_at': created,
# Mapper 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 en tant qu'IDs Bubble -- vous aurez besoin de construire une table de mappage pour convertir ceux-ci en vos nouvelles clés étrangères
- Les champs de fichiers s'exportent en tant qu'URLs CDN Bubble -- vous devez télécharger ces fichiers et les re-télécharger vers Supabase Storage avant que l'application Bubble ne se déconnecte
- Les champs de liste s'exportent en tant qu'IDs Bubble séparés par des virgules -- ceux-ci doivent devenir des tables de jonction appropriées
- Les formats de date sont incohérents -- testez votre analyse de date à fond
Pour l'API Data 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 Data 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 dans Next.js
L'éditeur visuel de Bubble se mappe de façon surprenante bien à l'architecture basée sur composants une fois que vous voyez le motif. Un « Élément réutilisable » Bubble est littéralement un composant React. Un « Groupe » Bubble est un <div> avec des classes Tailwind.
Voici un motif que j'utilise pour les pages qui étaient gourmandes en 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>
);
}
Notez comment la récupération des données se fait côté serveur. Pas de spinners de chargement, pas de requêtes en cascade. La page arrive complètement rendue. Cela seul rend l'application dramatiquement plus rapide que la version Bubble.
Pour les bibliothèques de composants, j'ai eu d'excellents résultats avec shadcn/ui. Cela 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 les interfaces utilisateur Bubble rapidement et elles seront plus réactives et performantes.
Configurer Supabase comme votre backend
Supabase Row Level Security est votre remplacement pour les Privacy Rules de Bubble, et honnêtement, c'est beaucoup plus puissant :
-- Permettre 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);
-- Permettre aux utilisateurs de mettre à jour uniquement leurs propres profils
CREATE POLICY "Users can update own profile"
ON user_profiles FOR UPDATE
USING (auth.uid() = user_id);
-- Permettre aux administrateurs 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 (choses qui s'exécutaient selon un horaire dans Bubble), Supabase Edge Functions avec pg_cron fonctionnent bien pour la plupart des cas d'usage. 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 :
- Forcer la réinitialisation du mot de passe -- Envoyer à tous les utilisateurs un email « nous avons mis à niveau notre plateforme » avec un lien de réinitialisation de mot de passe. Simple mais crée de la friction.
- Migration paresseuse -- Configurer un flux d'authentification personnalisé qui, à la première connexion, essaie de s'authentifier par rapport à l'API de Bubble. Si réussi, créer l'utilisateur dans Supabase avec le mot de passe qu'il vient de saisir.
L'option 2 est plus de travail mais une bien meilleure expérience utilisateur. Voici le croquis approximatif :
// app/api/auth/migrate-login/route.ts
export async function POST(request: Request) {
const { email, password } = await request.json();
// Essayer d'abord Supabase
const { data, error } = await supabase.auth.signInWithPassword({
email, password
});
if (data.user) return Response.json({ success: true });
// Si pas dans Supabase, essayer Bubble
const bubbleAuth = await authenticateWithBubble(email, password);
if (bubbleAuth.success) {
// Créer l'utilisateur dans Supabase avec le même mot de passe
const { data: newUser } = await supabase.auth.admin.createUser({
email,
password,
email_confirm: true,
});
// Migrer leurs données de profil
await migrateUserProfile(bubbleAuth.userId, newUser.user.id);
// Les connecter
return Response.json({ success: true });
}
return Response.json({ error: 'Invalid credentials' }, { status: 401 });
}
Performance et coûts après la migration
Voici des chiffres réels d'une SaaS de gestion de projet que j'ai aidé à migrer fin 2025 :
| Métrique | Sur Bubble | Après migration |
|---|---|---|
| Temps de chargement moyen | 3,8 s | 0,9 s |
| Time to Interactive | 5,2 s | 1,4 s |
| Performance Lighthouse | 38 | 92 |
| Coût mensuel d'infrastructure | 4 200 $ | 187 $ |
| Utilisateurs actifs mensuels | 12 000 | 12 000 |
| Temps de réponse API (p95) | 1 800 ms | 180 ms |
| Uptime (moyenne 3 mois) | 99,2 % | 99,97 % |
La réduction des coûts seule a justifié la migration en deux mois. Les améliorations de performance ont réduit le churn d'environ 15 % au cours du trimestre suivant.
Si vous regardez ces chiffres et pensez « je veux cela mais je n'ai pas l'équipe de dev pour le faire », c'est exactement le genre de projet que nous gérons. Consultez notre travail de développement CMS headless et d'applications ou contactez-nous pour une évaluation de migration.
Pièges courants et comment les éviter
Essayer de répliquer Bubble exactement
Ne faites pas cela. La façon de faire de Bubble est souvent la pire façon de faire les choses 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 deux fois plus longtemps que vous ne le pensez pour la migration des données. Les exports de données Bubble auront des cas limites qui vous surprendront. Des valeurs NULL où vous ne les attendiez pas. Des enregistrements en doublon. Des relations orphelines.
Oublier le stockage de fichiers
Bubble héberge vos fichiers téléchargés sur son CDN. Quand vous annulez votre plan Bubble, ces URL meurent. Assurez-vous que chaque seul fichier est téléchargé et re-téléchargé vers Supabase Storage avant de basculer.
Ne pas configurer la surveillance tôt
Dans Bubble, vous ne pensez pas à la surveillance parce que vous ne pouvez pas vraiment faire quelque chose à propos des problèmes de toute façon. Dans votre nouvelle pile, configurez Sentry pour le suivi d'erreurs et Vercel Analytics (ou Plausible/PostHog) pour la surveillance des performances dès le jour un.
Le faire 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 cela. Le coût d'une migration ratée -- perte de données, temps d'arrêt, churn des utilisateurs -- dépasse largement le coût de l'aide professionnelle. Notre page de tarification contient des détails sur à quoi ressemblent les engagements.
FAQ
Combien de temps faut-il pour migrer de Bubble vers Next.js et Supabase ?
Pour une application SaaS typique avec 10-30 pages et une complexité modérée, attendez-vous à 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 la 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'authentification des utilisateurs sont généralement ce qui prend plus de temps que prévu.
Puis-je migrer de Bubble progressivement, ou doit-ce être tout à la fois ?
Vous pouvez absolument le faire progressivement. Une approche courante est de construire la nouvelle application Next.js à côté de l'application Bubble, migrer les fonctionnalités une à une, 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 les considérer à la place ?
Si votre principal problème est la tarification de Bubble mais que vous voulez toujours une approche sans code/faible code, des outils comme WeWeb (frontend) + Xano (backend) peuvent fonctionner. Mais vous échangez un enfermement propriétaire contre un autre. Si vous dépassez Bubble à cause de la performance, 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 ponctuel qui évolue indéfiniment.
Combien coûte l'exécution d'une application Next.js + Supabase par rapport à Bubble ?
Pour la plupart des applications SaaS, vous regardez 45-200 $ par mois sur Vercel + Supabase pour ce qui coûterait 349-5 000 $ + par mois sur Bubble. Supabase Pro est 25 $ par mois, Vercel Pro est 20 $ par mois. À l'échelle, vos coûts augmentent beaucoup plus lentement parce que vous payez pour les ressources de calcul réelles plutôt que pour les unités de workflow. Une règle approximative : attendez-vous à payer 5-20 % de ce que vous payiez sur Bubble.
Mon SEO sera-t-il affecté par la migration ?
Il 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 un chargement plus rapide des pages et une meilleure capacité de crawl. Assurez-vous simplement que vous configurez des redirections 301 appropriées de vos anciennes URLs Bubble aux nouvelles routes Next.js, et vous devriez voir des améliorations 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 résume 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 une bonne occasion d'investir dans son apprentissage -- c'est une compétence qui paie des dividendes à jamais.
Que se passe-t-il pour les intégrations API de mon application Bubble pendant 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 Node.js Stripe. Faites une liste complète de chaque service externe avec lequel votre application Bubble parle et abordez-les une à la fois.
Puis-je utiliser la version gratuite de Supabase pour la production ?
La version gratuite de Supabase en 2026 vous donne 500 Mo de stockage de base de données, 1 Go de stockage de fichiers, et 50 000 utilisateurs actifs mensuels sur auth. Pour les produits en phase très précoce, cela peut fonctionner. Mais pour toute application de production sérieuse, vous voudrez le plan Pro à 25 $ par mois pour une meilleure performance, des sauvegardes quotidiennes, et pas de pause de projet après inactivité. C'est toujours absurdement bon marché comparé à Bubble.