Neon vs PlanetScale vs Turso : Postgres, MySQL ou SQLite à l'Edge ?

Le choix entre Neon, PlanetScale et Turso se résume à trois paris fondamentalement différents : Postgres, MySQL/Vitess et SQLite à l'edge. Le paysage a radicalement évolué au cours de l'année passée -- Databricks a acquis Neon pour environ 1 Md $, PlanetScale a lancé le support Postgres, et Turso a déprécié le scale-to-zero. Si tu choisis une base de données serverless en 2026, chaque comparaison que tu as lue est probablement obsolète.

Neon vs PlanetScale vs Turso en un coup d'œil

Choisis Neon si tu veux une compatibilité Postgres complète, un niveau gratuit généreux et la meilleure intégration Vercel. Choisis PlanetScale si tu as besoin de MySQL à l'échelle enterprise avec du sharding horizontal. Choisis Turso si la latence edge et les architectures multi-tenant une-base-par-utilisateur comptent le plus.

C'était la version courte. Le reste de cet article explique exactement pourquoi chaque cellule ressemble à ce qu'elle est.

Comment fonctionne chaque base de données sous le capot ?

Le moteur sous chaque plateforme détermine tout, de la syntaxe des requêtes aux limites de scalabilité. Comprendre l'architecture t'aide à prédire comment chacune se comportera à mesure que ton app grandit.

Neon : Postgres serverless avec branching

Neon sépare complètement le compute du stockage. Tes nœuds compute Postgres sont éphémères -- ils démarrent quand une requête arrive et s'arrêtent (ou passent à zéro) quand ils sont inactifs. Le stockage réside sur une couche pageserver distincte qui gère la durabilité et la récupération point-in-time.

Cette architecture active la fonctionnalité phare de Neon : le branching copy-on-write. Créer une branche de base de données est quasi-instantané quelle que soit la taille, car aucune donnée n'est copiée -- les pages de stockage sont partagées avec le parent et seules de nouvelles pages sont écrites quand les données changent. Pense à git branch pour ta base de données.

• Protocole wire PostgreSQL complet (pg_dump, psql, tout fonctionne)
• Autoscaling compute de 0,25 à 56 CU
• Pooling de connexions intégré via PgBouncer
• L'architecture de Neon utilise des safekeepers pour la durabilité du write-ahead log

PlanetScale : MySQL alimenté par Vitess (et maintenant Postgres)

PlanetScale tourne sur Vitess, le moteur de clustering MySQL construit à l'origine chez YouTube pour sharder leur base de données sur des dizaines de milliers de nœuds. Si tu as besoin de scalabilité horizontale pour MySQL, Vitess est la solution la plus éprouvée au monde.

La fonctionnalité DX signature de PlanetScale est les deploy requests -- essentiellement des pull requests pour les modifications de schéma. Tu proposes une migration, passes en revue le diff et l'appliques avec zéro downtime. Pas de locking, pas de fenêtres de maintenance.

Depuis septembre 2025, PlanetScale propose également Postgres géré. C'est un produit différent de leur offre Vitess -- des bases de données Postgres single-node à partir de 5 €/mois. Le sharding horizontal pour Postgres (appelé "Neki") est encore en développement.

Pour approfondir quand Postgres fait plus de sens que MySQL (et vice versa), consulte notre comparaison PostgreSQL vs MySQL.

• Vitess : sharding horizontal, migrations de schéma sans downtime
• Postgres : single-node, prêt pour la production, mais sans sharding encore
• Deploy requests pour des modifications de schéma sûres et révisables
• Pas de scale-to-zero -- les bases de données tournent en permanence

Turso : SQLite à l'edge avec libSQL

Turso adopte une approche complètement différente. Au lieu de faire tourner une base de données serveur, il utilise libSQL -- un fork open source de SQLite avec des capacités de mode serveur. Tes données peuvent vivre à l'edge, littéralement embarquées dans le runtime de ton application.

Le concept central est les répliques embarquées : des répliques de lecture qui tournent dans le processus de ton application (ou à des emplacements edge) avec des lectures à zéro latence réseau. Les écritures vont vers une instance primaire et se propagent aux répliques de façon asynchrone.

• libSQL étend SQLite avec l'accès HTTP, la réplication et la multi-tenancy
• Le modèle une-base-par-utilisateur supporte des milliers de bases de données isolées
• Les écritures se propagent du primaire aux répliques en millisecondes
• Idéal pour les apps read-heavy distribuées globalement

Verdict : Neon remporte en étendue architecturale. Postgres complet avec branching instantané couvre le plus large éventail de cas d'usage. PlanetScale gagne si tu as spécifiquement besoin de sharding horizontal de grade Vitess. Turso gagne si tu as besoin de données à l'edge.

Comment se comparent-ils en termes de performance et de latence ?

La performance est la question que les développeurs posent en premier, et la réponse dépend entièrement de si ta base de données est chaude ou froide.

Vérification de réalité sur les cold starts

Neon est la seule des trois qui fait encore du scale-to-zero par défaut. Quand ton nœud compute se réveille de l'inactivité, attends-toi à 400–750 ms sur la première requête. Les requêtes suivantes sont rapides. Tu peux éliminer les cold starts en définissant une taille compute minimale (0,25 CU coûte environ 7 €/mois).

PlanetScale a toujours été toujours-actif -- pas de cold starts, point. Ta base de données tourne que quelqu'un la requête ou non.

Turso a déprécié le scale-to-zero pour les nouveaux utilisateurs en janvier 2025. Les nouvelles inscriptions obtiennent des instances always-on, ce qui signifie pas de cold starts mais aussi pas d'économies "payer rien quand inactif".

Latence edge : où Turso brille

Pour les requêtes chaudes, les trois sont rapides. Mais les répliques embarquées de Turso livrent quelque chose que les deux autres ne peuvent pas : des lectures en millisecondes à un seul chiffre à l'edge. Quand ta réplique SQLite vit dans le même Cloudflare Worker ou Vercel Edge Function que ton code, il n'y a aucun saut réseau pour les lectures.

Les données de benchmark de Pilcrow (juillet 2023 -- à traiter comme directionnel, pas actuel) ont montré PlanetScale HTTP à ~8 ms, Neon HTTP à ~5 ms et Turso HTTP à ~27 ms pour des requêtes centralisées. Ces chiffres sont antérieurs au lancement Postgres de PlanetScale et aux changements d'infrastructure de Turso, donc prends-les comme points de référence plutôt que comme évangile.

Verdict : Turso gagne sur la latence edge. Les répliques embarquées avec des lectures sans saut réseau sont imbattables. Pour les workloads centralisés sans problèmes de cold start, la cohérence always-on de PlanetScale est difficile à battre. Les cold starts de Neon sont le compromis pour les économies scale-to-zero.

Combien coûte réellement chaque base de données ?

C'est là que la plupart des comparaisons échouent -- elles listent les prix des plans sans calculer ce qu'une vraie app paierait. Corrigeons ça.

Présentation du niveau gratuit

PlanetScale a supprimé son niveau Hobby gratuit en avril 2024. Le point d'entrée le moins cher est maintenant 5 €/mois pour une base de données Postgres single-node. Pour les bases de données Vitess/MySQL, la tarification est basée sur les clusters et significativement plus élevée.

Coût mensuel réel sur quatre niveaux de scale

Ces estimations utilisent les tarifs 2026 actuels des pages de tarification officielles de chaque plateforme. Les coûts réels varient selon les patterns d'utilisation.

Quelques points sautent aux yeux. Turso est remarquablement bon marché aux niveaux bas et moyen car son modèle de tarification par lecture de lignes favorise les apps read-heavy. La tarification usage-based de Neon signifie que tu ne paies que ce que tu consommes -- les bases de données inactives ne coûtent rien sur le niveau gratuit. La tarification de PlanetScale est compétitive pour les Postgres single-nodes mais monte avec les clusters Vitess.

La falaise tarifaire de PlanetScale

La plus grande faiblesse de PlanetScale pour les développeurs solo : il n'y a pas de niveau gratuit. Tu passes de 0 € (chez un concurrent) à 5 €/mois minimum. Pour les startups financées c'est sans importance, mais pour les projets perso et le prototypage, les niveaux gratuits de Neon et Turso sont bien meilleurs.

D'un autre côté, l'offre Vitess de PlanetScale fournit un sharding horizontal que ni Neon ni Turso ne peuvent égaler. Si ton débit d'écriture exige du sharding, la prime est justifiée.

Verdict : Neon gagne pour la plupart des budgets. Le niveau gratuit plus la tarification usage-based est le modèle le plus flexible. La tarification par lecture de lignes de Turso est excellente pour les apps read-heavy. PlanetScale coûte plus cher en bas de gamme mais offre une scalabilité de grade enterprise.

Comment est l'expérience développeur ?

La DX au quotidien compte plus que les chiffres de benchmark. Voici comment les trois se comparent sur les fonctionnalités que tu utiliseras vraiment.

Branching de base de données et CI/CD

Le branching copy-on-write de Neon est l'étalon-or. Crée une branche pour chaque PR, exécute des migrations dessus, teste avec des données similaires à la production, et merge. L'intégration Vercel crée automatiquement une branche par déploiement preview.

Les deploy requests de PlanetScale sont une autre déclinaison de la même idée. Au lieu de brancher toute la base de données, tu branches le schéma. Propose une migration, passe en revue le diff et applique-la avec zéro downtime. C'est plus opinioné mais sans doute plus sûr pour les modifications de schéma à l'échelle.

Turso n'a pas de branching. Tu gères les migrations avec l'outillage SQLite standard.

Matrice de compatibilité ORM

Neon et l'offre Postgres de PlanetScale fonctionnent avec tout l'écosystème ORM Postgres dès le départ. Turso nécessite des adaptateurs spécifiques à libSQL, bien maintenus mais plus limités.

CLI et développement local

Les trois ont de solides CLIs : neonctl pour Neon, pscale pour PlanetScale, et turso pour Turso. Chacun supporte la création de bases de données, la gestion des branches (le cas échéant) et la connexion depuis ton terminal.

Pour le développement local, les branches Neon brillent -- tu peux développer sur une branche qui reflète les données de production sans toucher à la production. Les branches de développement de PlanetScale servent un objectif similaire. Turso fait tourner SQLite localement, donc le développement local est ultra-simple -- pointe juste vers un fichier .db local.

Verdict : Neon gagne pour l'expérience développeur. Le branching copy-on-write avec l'intégration Vercel est la meilleure histoire CI/CD. Les deploy requests de PlanetScale sont excellents pour les équipes qui veulent une revue au niveau schéma. La simplicité de Turso est sous-estimée mais manque de branching.

Connexion depuis Next.js -- Code côte à côte

Voici à quoi ressemble la connexion à chaque base de données depuis une route API Next.js ou un Server Component. Prêts à copier-coller.

Connexion par driver brut (les trois)

Neon avec @neondatabase/serverless :

// lib/neon.ts
import { neon } from "@neondatabase/serverless";

const sql = neon(process.env.DATABASE_URL!);

// Fonctionne en Edge Runtime et Node.js
export async function getActiveUsers() {
  const users = await sql`
    SELECT * FROM users WHERE active = true
  `;
  return users;
}

PlanetScale avec @planetscale/database :

// lib/planetscale.ts
import { connect } from "@planetscale/database";

const conn = connect({
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
});

// Fonctionne en Edge Runtime et Node.js
export async function getActiveUsers() {
  const results = await conn.execute(
    "SELECT * FROM users WHERE active = true"
  );
  return results.rows;
}

Turso avec @libsql/client :

// lib/turso.ts
import { createClient } from "@libsql/client";

const turso = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN,
});

// Fonctionne en Edge Runtime et Node.js
export async function getActiveUsers() {
  const result = await turso.execute(
    "SELECT * FROM users WHERE active = 1"
  );
  return result.rows;
}

Remarque que Turso utilise = 1 au lieu de = true -- SQLite n'a pas de type booléen natif. Petite différence, mais ça surprend les gens.

Configuration de Drizzle ORM (les trois)

Si tu utilises Drizzle (et tu devrais probablement pour les requêtes type-safe), voici la config pour chacun :

// drizzle.config.ts — Neon
import { neon } from "@neondatabase/serverless";
import { drizzle } from "drizzle-orm/neon-http";

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql);

// drizzle.config.ts — PlanetScale (MySQL/Vitess)
import { connect } from "@planetscale/database";
import { drizzle } from "drizzle-orm/planetscale-serverless";

const connection = connect({
  host: process.env.DATABASE_HOST,
  username: process.env.DATABASE_USERNAME,
  password: process.env.DATABASE_PASSWORD,
});
export const db = drizzle(connection);

// drizzle.config.ts — Turso
import { createClient } from "@libsql/client";
import { drizzle } from "drizzle-orm/libsql";

const turso = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN,
});
export const db = drizzle(turso);

Les trois drivers fonctionnent dans Vercel Edge Functions et Cloudflare Workers. La surface API est suffisamment similaire que passer de l'un à l'autre est surtout un échange de driver -- ton schéma Drizzle et tes requêtes restent les mêmes (à l'exception des différences de dialecte SQL).

Peut-on utiliser plusieurs bases de données serverless ensemble ?

Voici un pattern qui gagne en traction dans la communauté mais qu'aucun article de comparaison ne mentionne : utiliser Turso pour les lectures edge et Neon pour les écritures.

L'idée est simple. Tes données primaires vivent dans Neon (Postgres complet, forte cohérence, support de requêtes riche). Tu répliques les données read-heavy vers des répliques edge Turso proches de tes utilisateurs globalement. Les lectures touchent Turso avec une latence sub-milliseconde ; les écritures vont vers Neon pour la durabilité et la cohérence.

Quand ça a du sens :

• Apps distribuées globalement où la latence de lecture compte (dashboards, plateformes de contenu)
• SaaS multi-tenant où les données read-heavy de chaque tenant bénéficient du cache edge
• Apps avec un ratio lecture/écriture 90/10 où tu peux tolérer des lectures légèrement périmées

Quand l'éviter :

• La plupart des apps n'ont pas besoin de lectures globales sub-10 ms -- une instance Neon single-region suffit
• La complexité de maintenir deux bases de données, synchroniser les données et gérer les pannes est réelle
• Si ton app est write-heavy, les lectures edge n'aident pas beaucoup

Sois honnête avec toi-même : si tu n'opères pas à l'échelle mondiale avec des exigences strictes de latence, ça ajoute de la complexité sans bénéfice significatif. Mais pour les apps qui en ont besoin, c'est un pattern vraiment élégant.

Qu'est-ce qui a changé en 2025–2026 ? (Les trois grands bouleversements)

Chaque comparaison concurrente a été écrite avant ces événements. Voici ce qui a changé et ce que ça signifie pour ta décision aujourd'hui.

Neon + Databricks : ce que signifie l'acquisition à 1 Md $

En mai 2025, Databricks a acquis Neon pour environ 1 milliard de dollars. Ce n'était pas qu'un événement financier -- ça a changé la trajectoire de Neon.

L'impact immédiat : Neon a réduit les coûts de stockage de 80 % (de 1,75 $ à 0,35 $ par Go-mois). L'analyse Vantage suggère que ça vient en partie des remises de volume AWS de Databricks répercutées sur les clients Neon.

Le signal stratégique : Databricks a indiqué que 80 % des bases de données Neon sont maintenant créées par des agents IA, contre 30 % au GA. Neon se positionne comme la base de données par défaut pour le développement piloté par l'IA -- création de schéma automatisée, données gérées par agents, provisionnement programmatique de bases de données.

Pour toi en tant que développeur, l'acquisition signifie : tarification moins chère, soutien enterprise (Databricks est rentable), et une roadmap de plus en plus optimisée pour les workflows programmatiques/IA.

PlanetScale Postgres : MySQL n'est plus la seule option

En septembre 2025, PlanetScale a lancé le support Postgres en GA. Ça change complètement l'ancien cadrage "Neon = Postgres, PlanetScale = MySQL".

PlanetScale Postgres commence à 5 €/mois pour des bases de données single-node avec des fonctionnalités comme Query Insights, les recommandations de schéma et le branching. C'est prêt pour la production et déjà utilisé par des centaines d'entreprises. Cependant, le sharding horizontal pour Postgres (leur projet "Neki") est encore en développement.

Ce que ça signifie : si tu choisis entre Neon vs PlanetScale purement sur la préférence de moteur, PlanetScale couvre maintenant les deux. Mais le Postgres de Neon est plus mature (il est Postgres-natif depuis le premier jour), a un niveau gratuit et offre un branching plus profond avec une sémantique copy-on-write. PlanetScale Postgres vaut la peine d'être surveilli mais Neon mène encore côté Postgres.

Turso abandonne le scale-to-zero : always-on par défaut

En janvier 2025, Turso a annoncé des changements importants de plateforme : scale-to-zero déprécié pour les nouveaux utilisateurs, consolidation de l'infrastructure vers AWS, et répliques edge discontinuées pour les nouvelles inscriptions.

Le compromis est clair : plus de cold starts (bien), mais plus d'économies "gratuit quand inactif" (moins bien). Les utilisateurs existants avec des plans legacy gardent le scale-to-zero, mais tous les autres obtiennent des instances always-on.

Ça rend Turso plus prévisible -- tu ne seras pas surpris par la latence cold start -- mais ça réduit aussi l'écart entre Turso et PlanetScale sur la dimension "serverless". Les deux sont maintenant des bases de données gérées always-on ; l'histoire edge de Turso est ce qui le différencie.

Neon vs PlanetScale vs Turso : lequel choisir ?

Assez d'analyse. Voici le cadre décisionnel.

Pour la plupart des développeurs démarrant un nouveau projet en 2026, Neon est le choix par défaut. Niveau gratuit, Postgres complet, branching instantané et intégration Vercel couvrent 80 % des cas d'usage. Tu peux toujours évoluer vers les plans payants ou changer plus tard -- l'écosystème Postgres signifie que tu n'es jamais verrouillé.

PlanetScale mérite sa place quand tu as besoin de MySQL à l'échelle enterprise ou que tu veux le workflow de deploy request pour des changements de schéma sans downtime dans de grandes équipes.

Turso est le bon choix quand ton architecture exige un accès aux données edge-first ou une isolation de base de données multi-tenant à l'échelle. C'est un outil spécialisé, et il est excellent dans ce en quoi il se spécialise.

Comment Techsy aborde la sélection de bases de données serverless

Nous évaluons les bases de données serverless selon quatre dimensions pour chaque projet client : complexité du modèle de données, taille de l'équipe et préférence de dialecte SQL, trajectoire de scalabilité sur les 12–18 prochains mois, et plateforme de déploiement (Vercel, Cloudflare, AWS, etc.).

Notre stack par défaut pour la plupart des projets est Neon + Drizzle + Next.js. Voici pourquoi :

1. Postgres nous donne l'écosystème le plus riche -- colonnes JSON, recherche plein texte, PostGIS, extensions
2. Le branching de Neon s'aligne parfaitement sur les déploiements preview et les pipelines CI
3. Le niveau gratuit nous permet de prototyper sans surcharge de facturation pour les clients en phase précoce
4. La type safety de Drizzle détecte le schema drift avant qu'il n'atteigne la production

Quand nous recommandons des alternatives :

• PlanetScale pour les équipes migrant depuis une infrastructure MySQL existante où réécrire les requêtes n'est pas pratique
• Turso pour les clients construisant des produits distribués globalement et read-heavy où la latence edge est une métrique business mesurable
• Parfois la réponse honnête est "utilise juste Supabase" quand tu as besoin d'auth + base de données + stockage dans un package géré

Besoin d'aide pour choisir la bonne base de données pour ton prochain projet ? Obtiens une consultation backend gratuite.

FAQ

Neon est-il meilleur que PlanetScale ?

Ça dépend de tes besoins. Neon est meilleur pour les équipes Postgres-natives, offre un niveau gratuit et a un branching de base de données plus profond avec une sémantique copy-on-write. PlanetScale est meilleur pour les workloads MySQL à l'échelle enterprise avec le sharding Vitess et les deploy requests sans downtime. Comme PlanetScale propose maintenant aussi Postgres, l'écart se réduit -- mais le Postgres de Neon est plus mature.

Quelle est la différence entre Neon et Turso ?

Neon est PostgreSQL serverless avec séparation compute-stockage et branching instantané. Turso est basé sur SQLite (libSQL) avec des répliques embarquées pour les lectures edge. Choisis Neon pour l'écosystème Postgres complet et les workflows de branching. Choisis Turso pour les lectures globales à faible latence et les architectures multi-tenant une-base-par-utilisateur.

PlanetScale vaut-il encore le coup sans niveau gratuit ?

Pour les projets hobby, probablement pas -- Neon et Turso offrent tous les deux des niveaux gratuits généreux. Pour les startups financées et les enterprises qui ont besoin de sharding horizontal alimenté par Vitess ou de deploy requests sans downtime, la tarification de PlanetScale est justifiée. Le point d'entrée Postgres à 5 €/mois est compétitif, bien que non gratuit.

Quelle est la meilleure base de données serverless pour Next.js ?

Neon, pour la plupart des développeurs. Elle a l'intégration Vercel la plus profonde (branche par déploiement preview), fonctionne avec tous les ORMs Postgres, et commence gratuitement. Turso est le choix si tu as spécifiquement besoin de lectures edge globales. Les trois ont des drivers qui fonctionnent dans Vercel Edge Functions.

À quel point les cold starts de Neon sont-ils mauvais en production ?

Attends-toi à 400–750 ms sur la première requête quand le compute se réveille de l'inactivité. Les requêtes suivantes sont rapides (ms à un seul chiffre). Pour les apps toujours réactives, mets le compute minimum à 0,25 CU (environ 7 €/mois sur le plan Launch) pour garder l'instance chaude et éliminer complètement les cold starts.

PlanetScale peut-il utiliser PostgreSQL maintenant ?

Oui, depuis septembre 2025. PlanetScale a lancé le support PostgreSQL en GA, avec des bases de données single-node à partir de 5 €/mois. C'est prêt pour la production avec des centaines d'entreprises qui tournent dessus. Cependant, le sharding horizontal pour Postgres est encore en développement -- pour ça, tu auras besoin de leur offre Vitess/MySQL.

Turso est-il bon pour les apps de production ?

Oui, avec des nuances. Turso excelle sur les workloads read-heavy et les architectures multi-tenant. La concurrence en écriture s'est significativement améliorée. Il est mieux adapté aux apps avec de hauts ratios lecture/écriture et des exigences de distribution globale. Pour les workloads transactionnels write-heavy, Neon ou PlanetScale sont de meilleurs choix.

Qu'est-il arrivé au niveau gratuit de PlanetScale ?

PlanetScale a supprimé son niveau Hobby (gratuit) en avril 2024. Les nouvelles bases de données Hobby ont été bloquées le 6 mars 2024, et toutes les existantes ont été retirées le 8 avril 2024. Le point d'entrée le moins cher est maintenant 5 €/mois pour une base de données Postgres single-node. Ça a poussé beaucoup de développeurs solo à migrer vers Neon ou Turso.

Comment l'acquisition par Databricks affecte-t-elle Neon ?

Databricks a acquis Neon pour ~1 Md $ en mai 2025. Depuis, Neon a réduit les coûts de stockage de 80 %, investi dans les workflows d'agents IA, et gagné en crédibilité enterprise. Les prix sont devenus moins chers, pas plus chers. L'acquisition signale une stabilité à long terme -- Databricks est rentable et engagé avec Neon comme sa couche Postgres.

Turso supporte-t-il encore le scale-to-zero ?

Turso a déprécié le scale-to-zero pour les nouveaux utilisateurs début 2025. Les utilisateurs existants avec des plans legacy le gardent, mais les nouvelles inscriptions obtiennent des instances always-on. Ça élimine les cold starts mais supprime l'avantage "payer rien quand inactif". Les répliques edge ont aussi été discontinuées pour les nouveaux utilisateurs dans le cadre de la consolidation de plateforme.

Quelle base de données serverless est la moins chère pour un projet perso ?

Neon et Turso offrent tous les deux des niveaux gratuits qui gèrent la plupart des projets perso. Neon te donne 0,5 Go de stockage et 100 heures de compute. Turso te donne 5 Go de stockage et 500 M de lectures de lignes. PlanetScale n'a pas de niveau gratuit -- le minimum est 5 €/mois. Pour un projet perso typique avec du trafic léger, l'un ou l'autre niveau gratuit est plus que suffisant.

Verdict final

Pour la plupart des développeurs en 2026, Neon est la meilleure base de données serverless pour démarrer. Elle te donne l'écosystème Postgres complet, un niveau gratuit qui fonctionne vraiment pour de vrais projets, un branching instantané pour CI/CD, et une tarification qui évolue avec l'usage. Le soutien Databricks ajoute la stabilité enterprise sans lock-in enterprise.

PlanetScale mérite sa place quand tu as besoin de sharding MySQL horizontal ou que ton équipe est déjà investie dans l'écosystème MySQL. Turso est le bon choix quand la latence edge est une exigence mesurable, pas juste un nice-to-have.

Évalue ton modèle de données, ta trajectoire de scalabilité, et où sont tes utilisateurs. Puis choisis et commence à construire -- les trois sont prêts pour la production, et les écosystèmes Postgres/MySQL/SQLite signifient que tu n'es jamais vraiment verrouillé.

Sources

• Architecture de Neon
• Tarification Neon
• Tarification PlanetScale
• PlanetScale pour Postgres est maintenant GA
• Tarification Turso
• Documentation libSQL de Turso
• Databricks s'engage à acquérir Neon
• Changements à venir sur la plateforme Turso
• PlanetScale déprécie le plan Hobby
• Benchmarks de latence de bases de données serverless -- Pilcrow (2023)
• Drizzle ORM -- Connecter Turso