Base de données EmDash : D1, SQLite, Turso ou PostgreSQL ?

EmDash ne vous enferme pas dans une base de données. Sa couche de données repose sur des abstractions portables : D1 est la cible naturelle sur Cloudflare, SQLite sert au développement local et aux déploiements Node.js, et Turso (libSQL) comme PostgreSQL sont pris en charge. Le même principe vaut pour les médias, qui peuvent aller dans R2, dans S3 ou sur le disque.

Le choix se fait dans un seul fichier, et il dépend surtout de l’endroit où vous déployez.

Où ça se configure

La base de données se déclare dans la configuration Astro, au moment où l’on ajoute l’intégration EmDash. L’adaptateur s’importe depuis le module emdash/db :

// astro.config.mjs
import emdash from "emdash/astro";
import { d1 } from "emdash/db";

export default defineConfig({
  integrations: [emdash({ database: d1() })],
});

Changer de base revient donc à changer d’adaptateur à cet endroit. Les adaptateurs des autres bases s’importent depuis le même module ; reportez-vous à la documentation officielle pour leur nom exact et leurs options, qui évoluent avec les versions.

Une fois le schéma en place, les types TypeScript se génèrent à partir de la base réelle :

npx emdash types

C’est ce qui permet au code de vos thèmes et de vos plugins de rester synchronisé avec les collections que vous avez définies. La commande fait partie de la CLI d’EmDash.

Les quatre options

Base	Où elle s’utilise	Pour qui
D1	En production sur Cloudflare Workers	Le déploiement de référence d’EmDash
SQLite	En local, et sur un serveur Node.js	Le développement, les petits sites sur un seul serveur
Turso / libSQL	Hébergé, compatible SQLite	Qui veut du SQLite managé hors de Cloudflare
PostgreSQL	Sur un serveur ou un service managé	Qui a déjà une infrastructure PostgreSQL

D1 : le choix par défaut sur Cloudflare

D1 est la base de données SQL de Cloudflare, construite sur SQLite. C’est la cible pour laquelle EmDash a été pensé : si vous déployez sur Workers, c’est l’option qui demande le moins de configuration et qui s’intègre au reste de l’écosystème. Le déploiement complet est détaillé dans notre guide pour déployer sur Cloudflare.

SQLite : le développement local

Pour travailler en local, EmDash tourne sur Node.js avec SQLite, sans compte Cloudflare. C’est ce qui rend l’installation si rapide : un fichier de base sur votre disque, et le site démarre. Voir installer EmDash.

SQLite convient aussi en production pour un site hébergé sur un seul serveur Node.js, avec un trafic raisonnable.

Turso et PostgreSQL : hors de Cloudflare

EmDash fonctionne au mieux sur Cloudflare, mais il n’y est pas enfermé. Turso propose une base compatible SQLite, hébergée et accessible à distance. PostgreSQL s’impose si votre équipe l’exploite déjà et sait le sauvegarder, le surveiller et le faire évoluer. Nous avons regroupé les autres points à connaître dans EmDash sans Cloudflare.

Et les médias ?

Les fichiers — images, documents, vidéos — ne vont pas dans la base de données. EmDash les confie à une couche de stockage séparée, elle aussi portable :

• R2, le stockage objet de Cloudflare, par défaut sur cette plateforme ;
• Amazon S3 et les services compatibles S3 ;
• le système de fichiers local, pour le développement et l’auto-hébergement.

La séparation a un intérêt pratique : on peut combiner une base et un stockage de fournisseurs différents, par exemple PostgreSQL et un stockage compatible S3. La gestion des images côté éditeur est détaillée dans images et médias.

Comment choisir

La question n’est pas « quelle est la meilleure base », mais « où vais-je déployer, et qui va l’exploiter ».

1. Vous déployez sur Cloudflare Workers : D1 et R2. C’est la voie la plus simple et la mieux documentée.
2. Vous déployez sur un seul serveur Node.js : SQLite pour commencer, avec un stockage local ou compatible S3.
3. Vous avez déjà une base PostgreSQL et une équipe qui l’administre : PostgreSQL.
4. Vous voulez du SQLite hébergé hors de Cloudflare : Turso.

Quel que soit le choix, deux précautions restent valables. Développez en local sur SQLite mais testez régulièrement sur la base de production, parce que des différences de comportement peuvent apparaître entre moteurs. Et prévoyez les sauvegardes dès le premier jour, pour la base comme pour les médias : notre guide sauvegarder EmDash passe en revue les méthodes pour chaque option.

Pour comprendre comment cette couche de données s’articule avec le reste — Astro, les plugins isolés, l’administration —, voir notre présentation de l’architecture d’EmDash.