Les benchmarks comparant D1, PlanetScale et Neon ont tendance à mesurer la mauvaise chose. Latence en microsecondes, débit en requêtes par seconde, résultats des requêtes synthétiques — aucun de ces chiffres ne répond à la question qui compte : laquelle de ces trois banques est adaptée à ce que vous construisez actuellement, en tenant compte de l'endroit où vos données vont croître, combien vous voulez payer alors que vous n'avez pas de trafic et quel dialecte SQL votre code suppose. Il existe trois architectures différentes avec des compromis différents, et non des variations de performances d'un même produit.
D1 : SQLite à la pointe sans coût pour commencer
L'argument central de D1 est l'intégration native avec Cloudflare Workers. Lorsqu'un Worker accède à une base de données D1 via une liaison, il n'y a pas de prise de contact TCP, il n'y a pas de chaîne de connexion, il n'y a pas de pool de connexions à gérer. La requête va directement à la liaison D1 dans le même contexte d'exécution, avec une latence inférieure à la milliseconde pour établir l'appel. Dans une architecture sans serveur où chaque milliseconde de temps système compte, cette intégration est réelle et mesurable.
Le niveau gratuit offre 5 Go de stockage, 5 millions de lignes lues par jour et 100 000 lignes écrites par jour – suffisamment pour le développement, les outils internes et les prototypes avec un faible trafic réel. Sur le forfait payant : 0,001 $ par million de lignes lues, 1 $ par million de lignes écrites, 0,75 $/Go-mois de stockage. Le développement local via wrangler dev --local crée un véritable fichier SQLite sur la machine, avec parité de comportement avec la base de données distante.
Les limites qui définissent où D1 n'est pas utile : 2 Go par banque, 10 banques dans le forfait payant, pas d'extensions SQLite personnalisées sauf sqlite-vec pour la recherche vectorielle. Une banque qui dépasse 2 Go n'a pas de chemin d'expansion au sein de D1 : vous devez diviser les données ou migrer vers une autre banque avant d'atteindre la limite. Pour les candidatures qui dépasseront, comme on pouvait s’y attendre, ce plafond, D1 est la bonne banque pour commencer et la mauvaise banque à conserver à long terme.
PlanetScale : MySQL avec partitionnement horizontal et branchement de schéma
PlanetScale est construit sur Vitess, la même infrastructure de base de données qui a fait évoluer MySQL de YouTube jusqu'à des volumes que MySQL standard ne peut pas gérer. Cette origine définit ce que propose PlanetScale : un véritable MySQL (la plupart des ORM fonctionnent sans modification), un partitionnement horizontal géré par la plate-forme à mesure que les données augmentent et le flux de travail de branchement de schéma qui distingue PlanetScale de toute autre base de données disponible aujourd'hui.
La branche de schéma fonctionne comme le contrôle de version pour le schéma : vous créez une branche de schéma, appliquez les modifications, testez et fusionnez à nouveau avec la branche principale. La migration s'exécute sans verrouiller les tables, contrairement au standard ALTER TABLE de MySQL, qui verrouille les écritures pendant l'exécution. Pour les équipes qui ont des difficultés avec les fenêtres de maintenance pour les migrations ou qui doivent annuler en toute sécurité les modifications de schéma, cette fonctionnalité résout un réel problème.
Le coût est le filtre le plus important : PlanetScale a mis fin à l'offre gratuite en 2024. Le plan Scaler commence à 39 $/mois. Pour les projets parallèles et les applications à un stade précoce sans revenus, cet étage élimine PlanetScale en option. Pour les produits avec des revenus constants et les équipes ayant une expérience MySQL, 39 $/mois pour ce que propose PlanetScale est raisonnable. La comparaison correcte n'est pas avec le D1 gratuit, mais avec le coût de la gestion manuelle du partitionnement MySQL lorsque le volume augmente.
Neon : du vrai PostgreSQL avec calcul sans serveur
Neon fournit PostgreSQL – pas un sous-ensemble compatible, pas SQLite avec une interface MySQL, mais le véritable runtime Postgres. Cette distinction est importante lorsque ce dont vous avez besoin n'existe dans aucune autre base de données sans serveur : PostGIS pour les données géospatiales, pg_trgm pour la recherche de texte flou, pg_partman pour le partitionnement automatique des tables, TimescaleDB pour les séries chronologiques, fonctions de fenêtre complexes que SQLite exécute avec des limitations.
Le modèle de calcul sans serveur de Neon, qui évolue jusqu'à zéro lorsqu'il n'y a pas de requêtes, le place dans une position intéressante pour les applications avec un trafic sporadique : vous ne payez pour le calcul que lorsque la base de données est activement consultée. Le forfait Pro coûte 19 $/mois avec 10 Go de stockage inclus. Pour les équipes qui disposent déjà du code PostgreSQL et ont besoin d'une base de données sans serveur sans migrer le dialecte SQL, Neon est le chemin le plus direct.
L'inconvénient par rapport au D1 dans un environnement Cloudflare Workers : Neon utilise un pooler de connexions (Neon Proxy) accessible via la chaîne de connexion standard PostgreSQL. Il n’y a pas de liaison native comme D1. La latence d'établissement de la connexion au proxy Neon dépend de la région Neon que vous avez configurée et de l'endroit où le Worker est exécuté. Elle peut être de 10 ms ou 80 ms selon la topologie, par rapport à moins d'une milliseconde pour D1.
Le coût de la migration entre les trois
Choisir une base de données au début d'un projet a un coût implicite qui n'apparaît que si le choix est erroné et que vous devez changer. Les trois banques ont des coûts de migration asymétriques.
Passer de D1 à Neon est techniquement réalisable mais pas trivial : wrangler d1 export génère un dump SQL dans le dialecte SQLite, qui doit être converti en PostgreSQL avant l'importation. La plupart des requêtes sont prises en charge, mais les comportements spécifiques de SQLite, tels que l'affinité de type, la sémantique d'AUTOINCREMENT par rapport à SERIAL, la gestion des dates, nécessitent un examen au cas par cas. Le volume des ajustements dépend de la mesure dans laquelle le code tire parti des particularités de SQLite.
Passer de PlanetScale à n'importe quelle autre base de données signifie passer de MySQL à SQLite (D1) ou PostgreSQL (Neon) — différents dialectes avec suffisamment de divergences de syntaxe pour nécessiter un réel effort de portabilité. Si le code utilise des transactions avec une syntaxe spécifique à MySQL, des fonctions de chaîne MySQL ou d'autres fonctionnalités propriétaires, la migration est plus coûteuse.
La règle qui simplifie la décision : si vous utilisez Cloudflare Workers et que vos données tiennent dans moins de 2 Go, D1 est la bonne valeur par défaut. Si vous avez besoin de PostgreSQL dès le départ — pour les extensions, pour la compatibilité avec les outils existants, pour les requêtes que SQLite ne prend pas bien en charge — commencez avec Neon plutôt que de migrer plus tard. PlanetScale intervient lorsque la mise à l'échelle horizontale de Vitess est une exigence, et non le prix d'entrée. Aucun des trois ne résout correctement les charges de travail analytiques : pour cela, le moteur d'analyse Cloudflare ou une base de données OLAP spécialisée constitue le chemin le plus court.
A lire aussi
- Email Routing vs Improvmx vs Forward Email : comparaison honnête
- Ouvriers + D1 + KV + R2 : composer des liaisons dans le même service
- DNS proxy vs DNS uniquement : ce qui change et quand chaque mode a du sens
- KV vs R2 vs API Cache : quand utiliser chaque niveau de stockage Cloudflare
- Cloudflare D1 : La base de données SQLite à la périphérie — et pourquoi « edge » ne signifie pas ce qu'il semble être
- Cloudflare Load Balancing et Geo Steering : quand le DNS devient une couche de trafic intelligente