Votre base de données de production atteint 100K enregistrements et vos temps de requête commencent à grimper. Vous rafraîchissez le dashboard — 2,4 secondes pour une liste filtrée qui s'affichait autrefois en 300ms. Votre client demande pourquoi son panneau d'administration se sent plus lent. Vous savez qu'il est temps d'évaluer si Supabase, Firebase, PlanetScale, Neon ou Turso peuvent vraiment gérer cette échelle. La plupart des articles de comparaison lancent une application todo et l'appellent une recherche. Nous avons exécuté 253 000+ enregistrements sur cinq sites clients en direct sur Supabase PostgreSQL pendant plus d'un an. Nous avons testé Firebase Firestore, PlanetScale, Neon et Turso sur des projets réels avec des modèles de trafic réels. Voici ce qui casse vraiment à l'échelle — et ce qui ne casse pas.

Si vous construisez une application web qui doit gérer 100K+ enregistrements avec des requêtes complexes, des fonctionnalités en temps réel et l'authentification, le choix de votre base de données définira votre architecture pendant des années. Choisissez mal et vous réécrivez votre couche de données en six mois ou payez 3x ce que vous devriez. Je veux vous épargner les deux.

Table des matières

Meilleure base de données pour sites 100K+ enregistrements : Supabase vs Firebase vs PlanetScale testé

Pourquoi cette comparaison existe

Chez Social Animal, nous construisons des applications web sans tête — principalement avec Next.js et Astro — pour des clients qui ont besoin de sites dynamiques et riches en données. Pensez à des annuaires d'entreprises avec 50K+ annonces, des sites de SEO programmatique générant des milliers de pages, et des tableaux de bord SaaS qui ont besoin de mises à jour en temps réel.

Quand un client nous vient avec un projet impliquant 100K+ enregistrements, la conversation sur la base de données se fait le jour un. Ce n'est pas une réflexion tardive. Le choix de votre base de données se propage à travers votre stratégie d'authentification, la conception de votre API, vos coûts d'hébergement, et votre capacité à livrer des fonctionnalités dans six mois.

Je ne vais pas prétendre que j'ai exécuté des charges de travail de production identiques sur les cinq bases de données. Ce serait malhonnête. Ce que j'ai fait, c'est exécuter une production sérieuse sur Supabase (253K+ enregistrements, cinq sites, 14 mois) et effectué des évaluations techniques approfondies des alternatives pour des projets clients spécifiques. Je serai clair sur les données provenant de la production et celles provenant de l'évaluation.

Les candidats en un coup d'œil

Avant de plonger profondément, voici le tableau rapide :

  • Supabase — PostgreSQL avec tous les accessoires (auth, stockage, temps réel, fonctions edge)
  • Firebase Firestore — Base de données NoSQL de Google avec d'excellents SDK mobiles
  • PlanetScale — MySQL sans serveur avec ramification de base de données (alimentée par Vitess)
  • Neon — PostgreSQL sans serveur avec ramification et mise à l'échelle à zéro
  • Turso — SQLite distribué en bordure (alimenté par libSQL)

Chacun est véritablement bon dans quelque chose. La question est de savoir si ce quelque chose correspond à ce que vous construisez.

Supabase PostgreSQL : notre cheval de bataille en production

Je vais commencer par Supabase car c'est là que nous avons l'expérience la plus approfondie. Sur cinq sites en production, notre plus grande table a 137K lignes (un système d'adresses national pour un projet d'annuaire), et nous sommes à 253K+ enregistrements totaux sur toutes les bases de données.

Ce que nous utilisons quotidiennement

Row Level Security (RLS) est probablement la fonctionnalité qui a scellé l'affaire pour nous. Quand vous construisez des applications multi-locataires — ce que la plupart des sites pilotés par CMS sans tête finissent par devenir — vous avez besoin d'isolation des données par utilisateur. Avec RLS, la logique de sécurité vit dans la base de données elle-même. Votre couche API n'a pas besoin de se souvenir de filtrer par user_id sur chaque requête. La base de données l'applique.

Voici à quoi ressemble une politique RLS typique dans nos projets :

-- Les utilisateurs ne peuvent voir que les annonces de leur propre organisation
CREATE POLICY "org_isolation" ON listings
  FOR SELECT
  USING (org_id = (SELECT org_id FROM profiles WHERE id = auth.uid()));

-- Les administrateurs peuvent tout voir
CREATE POLICY "admin_access" ON listings
  FOR ALL
  USING (EXISTS (
    SELECT 1 FROM profiles
    WHERE id = auth.uid() AND role = 'admin'
  ));

C'est du vrai SQL. Ce n'est pas un DSL propriétaire. Si vous avez jamais besoin de quitter Supabase, ces politiques se traduisent par n'importe quel hôte PostgreSQL.

pgvector a été une révélation pour la recherche sémantique. Nous l'avons implémenté sur un site riche en contenu où la recherche en texte intégral ne donnait pas satisfaction. Les utilisateurs recherchaient « endroits où manger près du centre-ville » et s'attendaient à des résultats incluant des restaurants, des cafés et des camions de nourriture — même si ces mots exacts n'étaient pas dans l'annonce.

-- Créer la colonne vectorielle
ALTER TABLE listings ADD COLUMN embedding vector(1536);

-- Créer l'index (cela importe BEAUCOUP avec 100K+ enregistrements)
CREATE INDEX ON listings USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 100);

-- Requête de recherche sémantique
SELECT id, name, 1 - (embedding <=> $1) AS similarity
FROM listings
WHERE 1 - (embedding <=> $1) > 0.78
ORDER BY embedding <=> $1
LIMIT 20;

Avec 137K enregistrements avec des vecteurs de dimension 1536, cette requête s'exécute en ~45ms sur le plan Supabase Pro. C'est assez rapide pour la recherche en temps réel au fur et à mesure de la saisie.

PostGIS les requêtes géo alimentent nos fonctionnalités basées sur la localisation. Trouver des annonces dans un rayon, trier par distance, calculer les temps de trajet — tout est géré au niveau de la base de données plutôt que dans le code applicatif.

-- Trouver des annonces dans un rayon de 10km d'un point, ordonnées par distance
SELECT id, name,
  ST_Distance(location, ST_MakePoint(-73.9857, 40.7484)::geography) AS distance_m
FROM listings
WHERE ST_DWithin(
  location,
  ST_MakePoint(-73.9857, 40.7484)::geography,
  10000
)
ORDER BY distance_m
LIMIT 50;

Les abonnements en temps réel nous permettent de construire des tableaux de bord en direct sans infrastructure WebSocket. Un panneau d'administration client affiche les nouvelles soumissions apparaissant instantanément car nous nous abonnons aux événements INSERT sur la table pertinente. Zéro infrastructure supplémentaire.

Ce qui n'est pas parfait

Je n'ai pas l'intention de prétendre que Supabase est sans défaut. Le tableau de bord peut être lent quand vous parcourez des tables avec 100K+ lignes. L'éditeur de table va bien pour les petits ensembles de données mais est pénible pour les opérations en masse — vous voudrez utiliser SQL directement. Leurs Edge Functions sont alimentées par Deno, ce qui signifie que certains packages Node.js ne fonctionnent pas. Et si vous avez besoin de connection pooling pour les environnements sans serveur, vous devez utiliser leur chaîne de connexion Supavisor (ils ont déprécié PgBouncer au début de 2025).

Aussi, leur niveau gratuit est véritablement généreux pour le développement mais a une limite dure de 500MB d'espace de base de données. Pour la production avec 100K+ enregistrements, vous regardez le plan Pro minimum ($25/mois).

Meilleure base de données pour sites 100K+ enregistrements : Supabase vs Firebase vs PlanetScale testé - architecture

Firebase Firestore : où il gagne et où il ne gagne pas

Nous avons évalué Firebase sérieusement pour deux projets clients en 2024. L'un était une application d'abord mobile avec des exigences de synchronisation hors ligne. L'autre était un site d'annuaire avec un filtrage complexe.

Où Firebase gagne vraiment

La synchronisation en temps réel de Firebase pour les applications mobiles est toujours la meilleure de sa catégorie. La persistance hors ligne, la résolution automatique des conflits et l'intégration étroite avec les SDK iOS/Android en font le choix évident si votre plateforme principale est le mobile. L'intégration Google Auth est très simple — quelques lignes de code et vous avez Sign-in with Google, Apple, numéro de téléphone et email/mot de passe.

Firebase Crashlytics, Remote Config et Analytics forment un écosystème de développement mobile qu'aucune autre chose ne correspond. Si vous construisez une application mobile en premier et une application web en second, Firebase mérite une considération sérieuse.

Pourquoi nous avons choisi Supabase à la place

Firestore est une base de données documentaire. Pas de jointures. Laissez cela s'enfoncer dans vous pendant un moment.

Quand vous construisez un annuaire avec des annonces qui ont des catégories, des balises, des emplacements, des avis et des profils d'utilisateurs, vous avez besoin de données relationnelles. Dans Firestore, vous dénormalisez tout (en dupliquant les données sur les documents et en priant de les garder synchronisées) ou vous effectuez plusieurs requêtes d'aller-retour et joignez les données dans le code de votre application.

Voici à quoi ressemble une requête « trouver des annonces par catégorie avec classement moyen » dans chacune :

-- Supabase : une requête, terminé
SELECT l.*, c.name AS category_name,
  AVG(r.rating) AS avg_rating,
  COUNT(r.id) AS review_count
FROM listings l
JOIN categories c ON l.category_id = c.id
LEFT JOIN reviews r ON r.listing_id = l.id
WHERE c.slug = 'restaurants'
GROUP BY l.id, c.name
ORDER BY avg_rating DESC
LIMIT 20;

// Firestore : trois requêtes + jointure côté client
const categorySnap = await db.collection('categories')
  .where('slug', '==', 'restaurants').get();
const categoryId = categorySnap.docs[0].id;

const listingsSnap = await db.collection('listings')
  .where('categoryId', '==', categoryId).get();

// Maintenant récupérer les avis pour chaque annonce...
// Puis calculer les moyennes dans le code applicatif...
// Puis trier... vous comprenez l'idée.

Et voici le vrai coup : Firestore facture par lecture de document. Ce modèle de triple requête ci-dessus ? Chaque document dans chaque requête compte. Avec 100K+ enregistrements et un trafic modéré, votre facture devient véritablement imprévisible. Nous avons entendu des histoires d'horreur de factures surprises de $400+ de développeurs qui ne réalisaient pas que leurs requêtes analysaient plus de documents que prévu.

Firestore n'a pas non plus d'équivalent à pgvector ou PostGIS. Vous pouvez faire des requêtes geohash basiques, mais elles sont approximatives et limitées par rapport à l'indexation spatiale véritable.

PlanetScale : excellente base de données, plateforme incomplète

PlanetScale exécute Vitess sous le capot — la même technologie qui alimente la base de données de YouTube. Pour les performances pures de MySQL, c'est excellent. Leur fonctionnalité de ramification de base de données (créer une branche, apporter des changements de schéma, fusionner en arrière) est véritablement innovante et quelque chose que j'aimerais que Supabase ait nativement.

Ce que PlanetScale fait bien

Leur pilote sans serveur est rapide. La gestion des connexions est traitée pour vous, ce qui importe énormément dans les environnements sans serveur où chaque invocation de fonction pourrait sinon ouvrir une nouvelle connexion de base de données. La ramification de schéma rend les migrations de base de données ressembler à des demandes de tirage Git — sûres, révisables, réversibles.

Pour les équipes avec une expertise MySQL forte construisant des applications web traditionnelles, PlanetScale est solide.

Ce qui manque

PlanetScale est juste une base de données. C'est tout. Comparez ce dont vous avez besoin pour construire une pile d'application complète :

Fonctionnalité Supabase PlanetScale + Extras
Base de données ✅ Inclus ✅ Inclus
Auth ✅ Inclus ❌ Besoin Clerk ($25+/mois) ou Auth0
Stockage fichier ✅ Inclus ❌ Besoin S3 ou Cloudflare R2
Temps réel ✅ Inclus ❌ Besoin Pusher ou Ably
Recherche vectorielle ✅ pgvector ❌ Non disponible
Requêtes géo ✅ PostGIS ❌ MySQL spatial basique
Edge Functions ✅ Inclus ❌ Besoin déploiement séparé

Dès que vous avez ajouté Clerk pour l'auth, S3 pour le stockage, Pusher pour le temps réel, et une base de données vectorielle séparée pour la recherche, vous gérez cinq services au lieu d'un. Votre facture est plus élevée, votre complexité est plus élevée, et votre surface d'attaque de débogage est énorme.

PlanetScale a également arrêté son niveau gratuit (plan Hobby) en avril 2024, donc le point d'entrée est maintenant $39/mois pour leur plan Scaler. C'est plus cher que Supabase Pro et vous donne moins de fonctionnalité.

Neon : le choix du puriste

Neon est la base de données que je choisirais si j'avais juste besoin de PostgreSQL et rien d'autre. Leur architecture sans serveur est véritablement impressionnante — la mise à l'échelle à zéro signifie que vous ne payez rien quand votre base de données n'est pas interrogée. Leur fonctionnalité de ramification est excellente pour les déploiements d'aperçu (créer une branche de base de données pour chaque PR).

Neon supporte pgvector et PostGIS car c'est PostgreSQL standard. Donc vous obtenez la recherche vectorielle et les requêtes géo. Les capacités brutes de la base de données sont presque identiques à Supabase.

Pourquoi nous avons toujours choisi Supabase

Neon est une base de données. Supabase est une plateforme. Avec Neon, vous devez ajouter :

  1. Auth — Clerk, Auth0, ou implémenter le vôtre
  2. Stockage — S3, Cloudflare R2, ou similaire
  3. Temps réel — Pusher, Ably, ou un serveur WebSocket personnalisé
  4. Edge Functions — Déployer sur Cloudflare Workers ou Vercel séparément

Pour certaines équipes, cette approche modulaire est en fait préférable. Si vous avez déjà des opinions sur l'auth (et le budget pour Clerk), utilisez S3 pour tout, et ne l'avez pas besoin de temps réel, l'approche focalisée de Neon signifie moins de verrouillage au fournisseur.

Mais pour nos projets de développement sans tête, avoir l'auth, le stockage et le temps réel dans un seul tableau de bord avec une seule facture et un seul ensemble de clés API vaut beaucoup. La vélocité des développeurs importe quand vous livrez des projets clients sur des calendriers serrés.

La tarification de Neon est également compétitive : leur niveau gratuit inclut 0,5GB de stockage et 190 heures de calcul/mois. Le plan Launch à $19/mois vous donne 10GB. Pour un jeu de base de données pur, c'est la meilleure valeur dans PostgreSQL sans serveur.

Turso : SQLite optimisé pour les bordures

Turso est une technologie fascinante. Ils ont pris SQLite — la base de données la plus déployée du monde — et l'ont rendue distribuée. Vos données vivent à la bordure, près de vos utilisateurs, ce qui signifie que la latence de lecture peut être incroyablement basse (sub-10ms mondialement).

Où Turso brille

Chargements de travail lourds en lecture avec des audiences mondiales. Si vous servez du contenu qui ne change pas fréquemment aux utilisateurs du monde entier, la réplication en bordure de Turso vous donne des lectures de base de données qui se sentent instantanées. Leur fonctionnalité de répliques embarquées vous permet de regrouper un réplica SQLite directement dans votre application.

Pour les sites statiques avec Astro qui ont besoin d'une couche de données légère, Turso est convaincant.

Pourquoi cela ne correspondait pas à nos besoins

Nos charges de travail 100K+ enregistrements impliquent des écritures significatives — soumissions d'utilisateurs, mises à jour d'admin, création d'avis, modifications de données en temps réel. Le modèle d'écriture SQLite (rédacteur unique) devient un goulot d'étranglement à l'échelle. Turso gère cela mieux que SQLite brut via leur fork libSQL, mais c'est toujours pas conçu pour les applications 100K+ enregistrements lourdes en écriture.

Pas de recherche vectorielle. Pas d'équivalent PostGIS. Écosystème limité par rapport à PostgreSQL ou MySQL. Pour nos projets d'annuaire et SaaS, c'était un obstacle rédhibitoire.

Comparaison des fonctionnalités tête-à-tête

Voici le tableau de comparaison complet basé sur notre expérience de production et nos évaluations à partir de mi-2026 :

Fonctionnalité Supabase Firebase PlanetScale Neon Turso
Type de base de données PostgreSQL NoSQL (Firestore) MySQL (Vitess) PostgreSQL SQLite (libSQL)
Auth intégrée ✅ Oui ✅ Oui ❌ Non ❌ Non ❌ Non
Recherche vectorielle ✅ pgvector ❌ Non ❌ Non ✅ pgvector ❌ Non
Requêtes géo ✅ PostGIS ⚠️ Limité (Geohash) ⚠️ MySQL spatial basique ✅ PostGIS ❌ Non
Temps réel ✅ Oui ✅ Oui ❌ Non ❌ Non ❌ Non
Stockage fichier ✅ Oui ✅ Oui ❌ Non ❌ Non ❌ Non
Edge Functions ✅ Basée sur Deno ✅ Cloud Functions ❌ Non ❌ Non ❌ Non
Jointures / Relations ✅ SQL complet ❌ Pas de jointures ✅ SQL complet ✅ SQL complet ✅ SQL (limité)
Ramification ⚠️ Via migrations ❌ Non ✅ Native ✅ Native ❌ Non
Mise à l'échelle à zéro ❌ Non ✅ Oui ✅ Oui ✅ Oui ✅ Oui
Prévisibilité des tarifs 🟢 Haute (tiers fixes) 🔴 Basse (par lecture) 🟡 Moyen 🟢 Haute 🟢 Haute
Open Source ✅ Oui ❌ Non ❌ Non (Vitess est) ✅ Oui ✅ Oui
Auto-hébergeable ✅ Oui ❌ Non ❌ Non ❌ Non ✅ Oui

Benchmarks de performance avec 100K+ enregistrements

Ces nombres proviennent de notre instance Supabase de production (plan Pro, région us-east-1) avec 137K lignes dans la table principale. Pour les autres bases de données, j'utilise les benchmarks publiés et nos tests d'évaluation avec 100K enregistrements synthétiques.

Type de requête Supabase Firebase PlanetScale Neon Turso
SELECT simple par ID 3ms 8ms 4ms 5ms 1ms
Requête filtrée (indexée) 12ms 15ms 10ms 14ms 3ms
Jointure complexe (3 tables) 35ms N/A (pas de jointures) 28ms 38ms 25ms
Similarité vectorielle (top 20) 45ms N/A N/A 42ms N/A
Rayon géo (10km) 22ms ~50ms (geohash) N/A 24ms N/A
Recherche en texte intégral 18ms N/A (utiliser Algolia) 15ms 20ms 12ms
Insertion en masse (1000 lignes) 180ms 250ms 150ms 195ms 320ms
Démarrage à froid (sans serveur) N/A (toujours actif) ~100ms ~50ms ~300ms ~20ms

Quelques éléments ressortent. Les performances de lecture de Turso sont exceptionnelles — c'est l'avantage SQLite-en-bordure. Le moteur MySQL de PlanetScale gère les jointures légèrement plus rapidement que PostgreSQL dans nos tests. Le démarrage à froid de Neon est notable (300ms) car il doit réveiller le calcul, bien que les requêtes ultérieures soient rapides. Le manque de jointures Firebase signifie que vous ne pouvez littéralement pas exécuter certaines de ces requêtes.

Le calcul toujours actif de Supabase (pas de mise à l'échelle à zéro sur Pro) signifie zéro démarrage à froid, ce qui importe pour les applications orientées utilisateurs où cette première requête ne peut pas être lente.

Ventilation des tarifs pour les charges 100K enregistrements

Modélisons une application 100K-enregistrements réaliste : un site d'annuaire avec 100K annonces, 50K utilisateurs actifs mensuels, ~2M lectures de base de données/mois, ~50K écritures/mois, 5GB de taille de base de données, 10GB de stockage fichier.

Supabase Pro Firebase (Blaze) PlanetScale Scaler Neon Launch Turso Scaler
Coût de base $25/mois $0 (pay-as-you-go) $39/mois $19/mois $29/mois
Base de données Inclus (8GB) ~$18 (lectures + écritures) Inclus (10GB) Inclus (10GB) Inclus (9GB)
Auth Inclus (50K MAU) Inclus +$25/mois (Clerk) +$25/mois (Clerk) +$25/mois (Clerk)
Stockage (10GB) Inclus ~$3/mois +$2/mois (R2) +$2/mois (R2) +$2/mois (R2)
Temps réel Inclus Inclus +$25/mois (Pusher) +$25/mois (Pusher) +$25/mois (Pusher)
Total estimé $25/mois ~$21/mois ~$91/mois ~$71/mois ~$81/mois

Firebase semble bon marché jusqu'à ce que vous réalisiez deux choses. Premièrement, cette estimation de $21 suppose des modèles de lecture prévisibles. Un moment viral ou un bot parcourant votre site peut augmenter les lectures de façon spectaculaire — et votre facture monte avec. Deuxièmement, une fois que vous avez besoin de fonctionnalités comme la recherche vectorielle, vous ajoutez Pinecone ou Weaviate, ce qui commence à $70/mois.

Le plat $25/mois de Supabase pour tout — base de données, auth, stockage, temps réel, edge functions — est d'une valeur remarquablement bonne pour cette taille de charge de travail. Le plan Pro inclut 8GB de base de données, 250GB de bande passante, 100GB de stockage, et 50K utilisateurs actifs mensuels pour l'auth.

Quelle base de données devriez-vous choisir ?

Voici ma recommandation honnête basée sur la construction avec ces outils :

Choisissez Supabase si vous construisez une application web avec des données relationnelles, avez besoin d'auth + stockage + temps réel dans une plateforme, voulez l'écosystème de PostgreSQL (pgvector, PostGIS, recherche en texte intégral), ou vous construisez avec Next.js. Cela couvre probablement 80% des projets que nous voyons.

Choisissez Firebase si vous construisez une application d'abord mobile où la synchronisation hors ligne importe, votre équipe connaît déjà l'écosystème Firebase, ou vos données sont véritablement document-façonnées (messages de chat, flux d'activité, profils d'utilisateurs simples).

Choisissez PlanetScale si vous avez une forte équipe MySQL, avez besoin de ramification de base de données pour la gestion complexe des schémas, et vous utilisez déjà des services séparés pour l'auth et le stockage. C'est une excellente base de données — juste pas une plateforme complète.

Choisissez Neon si vous voulez PostgreSQL sans les frais de plateforme, préférez assembler votre propre pile à partir de services meilleurs de race, ou avez besoin de mise à l'échelle à zéro pour l'optimisation des coûts sur les projets à faible trafic.

Choisissez Turso si vous construisez une application distribuée mondialement lourde en lecture où la latence en bordure importe plus que le débit d'écriture, ou vous travaillez avec Astro sur des sites centrés sur le contenu.

Pour notre travail chez Social Animal en construisant des applications web sans tête, Supabase s'est avéré être le bon appel. La plateforme tout-en-un signifie un développement plus rapide, une architecture plus simple, et des coûts prévisibles. Nous l'avons mis à l'échelle à 253K+ enregistrements sans transpirer. Si vous planifiez un projet à cette échelle et voulez parler architecture, contactez-nous — nous avons fait cela quelques fois maintenant.

FAQ

Supabase est-il bon pour les applications à grande échelle ?

Oui, et nous avons des preuves de production pour le sauvegarder. Nous exécutons 253K+ enregistrements sur cinq sites de production sur Supabase Pro. Les performances des requêtes restent cohérentes — nos jointures les plus complexes avec recherche de similarité vectorielle s'exécutent en moins de 50ms à 137K lignes. Supabase s'exécute sur PostgreSQL standard, qui alimente des applications des ordres de grandeur plus grandes que tout ce que la plupart d'entre nous construirons. La couche plateforme (auth, stockage, temps réel) est la partie la plus récente, mais elle s'est avérée stable pour nous depuis début 2024.

Comment la tarification de Supabase se compare-t-elle à Firebase à l'échelle ?

Subabase est dramatiquement plus prévisible. Leur plan Pro est un plat $25/mois qui inclut l'auth pour 50K MAU, 8GB de stockage de base de données, 250GB de bande passante, et 100GB de stockage fichier. Firebase facture par lecture, écriture et suppression de document — ce qui rend les coûts hautement variables. Une application 100K-enregistrements avec 2M lectures mensuelles pourrait coûter entre $15 et $200+ sur Firebase selon les modèles de requête. Nous avons vu les factures Firebase tripler du jour au lendemain quand une page était partagée sur les réseaux sociaux.

PlanetScale peut-il gérer 100K+ enregistrements ?

Absolument. PlanetScale exécute Vitess, qui alimente les charges de travail à l'échelle de YouTube. Pour les performances pures de base de données avec 100K enregistrements, PlanetScale est excellent. La limitation n'est pas l'échelle — c'est la complétude. Vous devez ajouter des services séparés pour l'auth, le stockage fichier, les mises à jour en temps réel, et la recherche vectorielle. Cela ajoute à la fois un coût ($90+/mois total) et une complexité architecturale par rapport à l'approche tout-en-un de Supabase.

Qu'est-ce que pgvector et pourquoi cela importe-t-il ?

pgvector est une extension PostgreSQL qui stocke et interroge directement les embeddings vectoriels dans votre base de données. Cela permet la recherche sémantique — les utilisateurs peuvent chercher par sens plutôt que par mots exacts. Pour un annuaire avec 100K+ annonces, cela signifie qu'une recherche pour « endroits pour petit-déjeuner adaptés aux enfants » peut retourner des résultats marqués comme « restaurant familial » ou « petit-déjeuner de fin de semaine » même si ces mots ne correspondent pas. Sans pgvector, vous auriez besoin d'une base de données vectorielle séparée comme Pinecone ($70+/mois) et de traiter avec la synchronisation de deux bases de données.

Firebase Firestore est-il bon pour les sites d'annuaire ?

Honnêtement, non. Les sites d'annuaire sont intrinsèquement relationnels. Les annonces appartiennent à des catégories, ont des balises, reçoivent des avis des utilisateurs, et ont besoin de filtrage complexe (« montrez-moi les restaurants à moins de 5 miles avec 4+ étoiles qui sont ouverts maintenant »). Firestore ne peut pas faire de jointures, a des opérateurs de requête limités, et facture par lecture de document — ce qui signifie que les requêtes filtrées complexes deviennent chères rapidement. Nous avons évalué Firestore pour un projet d'annuaire et estimé 4x le temps de développement par rapport à Supabase en raison de la dénormalisation de données et des contournements de requête côté client.

Dois-je utiliser Neon ou Supabase pour mon application Next.js ?

Si vous avez juste besoin d'une base de données, Neon offre une meilleure valeur (le niveau gratuit est généreux, et le plan Launch à $19/mois est solide). Si vous avez besoin d'auth, stockage, temps réel, ou edge functions — ce que la plupart des applications Next.js de production font — Supabase vous épargne d'intégrer et payer pour plusieurs services séparés. Nous utilisons Supabase pour nos projets de développement Next.js car l'auth et le stockage intégrés coupent des semaines des calendriers de projet typiques.

Quelle est la meilleure base de données pour les sites SEO programmatique ?

Supabase PostgreSQL. Les sites SEO programmatique génèrent des milliers de pages à partir de données structurées, ce qui signifie que vous avez besoin de requêtes rapides, d'un bon indexage, et de la capacité à gérer les relations de données complexes. Nous avons construit des sites SEO programmatique sur Supabase qui génèrent 10K+ pages à partir d'une seule base de données — PostGIS pour les pages de localisation, pgvector pour le contenu associé, et recherche en texte intégral pour le filtrage dynamique. La tarification plate signifie que les pics de trafic de Google l'indexation ne vous font pas exploser la facture.

Turso (libSQL) est-il prêt pour les applications web de production ?

Pour les applications lourdes en lecture, oui. SQLite distribué au bord de Turso vous donne des lectures sub-5ms mondialement, ce qui est incroyable pour les sites centrés sur le contenu. Mais pour les applications lourdes en écriture avec 100K+ enregistrements — comme les annuaires où les utilisateurs soumettent des données, les panneaux d'administration traitent les mises à jour, et les avis arrivent constamment — le modèle d'écriture unique de SQLite devient limitant. Nous recommandons Turso pour les sites de contenu construits avec Astro et Supabase ou Neon pour les applications dynamiques avec des charges de travail d'écriture significatives.