← outils
Appwrite

Appwrite

Le backend open source qui vise les agents.

visiter l'outil →freemiumAuto-hébergement gratuit (BSD-3-Clause). Cloud : Free 0 $, Pro dès 25 $/mois, Enterprise sur devis. Dépassements à l'usage (bande passante, stockage, lectures/écritures). Compute dédié base de données de 10 $ à 960 $/mois.

points forts

  • + Open source BSD-3-Clause, auto-hébergement gratuit sans les quotas du cloud
  • + Moteur Hyperloop B : instance par défaut réduite de 33 à 16 conteneurs
  • + PostgreSQL natif, VectorsDB, DocumentsDB et Embeddings API intégrés
  • + API compatible S3 et fournisseur OAuth 2.1 / OpenID Connect
  • + Positionnement agent-first : serveur MCP hébergé, intégrations Claude Code, Codex, Cursor

points faibles

  • Nouveautés phares (VectorsDB, DocumentsDB, Embeddings) désactivées par défaut
  • PostgreSQL par défaut ne migre pas les instances existantes (moteur figé)
  • Self-hosted 2.0 incomplet : pare-feu, API S3 et journaux encore cloud-only
  • 990 issues ouvertes et faible relais externe pour une refonte majeure

review complète

Appwrite Le backend qui vous vend du repos, facturé au conteneur

État des lieux

Septembre 2026 aura été le mois où Appwrite, la plateforme backend open source d'Eldad Fux, a décidé de faire sa mue. Annoncée le 31 août, livrée en auto-hébergement le 7 septembre, poussée sur Product Hunt le 15 : la version 2.0 est sortie en clôture d'une semaine de lancements baptisée « Init 2026 », cinq jours, cinq annonces, trois versions en onze jours (2.0.0 le 4, 2.1.0 le 11, 2.2.0 le 15). Le dépôt affiche 57 391 étoiles, 5 723 forks et 990 issues ouvertes. La promesse tient en une phrase : un moteur réécrit (Hyperloop B, coroutines Swoole, « jusqu'à 7x plus de requêtes » selon l'éditeur), une console refaite (Console IV), PostgreSQL en base par défaut, et une pile de nouveautés VectorsDB, DocumentsDB, Embeddings API, API compatible S3, serveur OAuth 2.1, pare-feu, registrar de domaines. Le tout adossé à un positionnement assumé sur la page d'accueil : « plateforme MCP et agent-first ».

La carte des menus

Le code est en BSD-3-Clause et l'auto-hébergement est gratuit, sans les quotas du cloud. Côté cloud, trois paliers : Free à 0 $ (5 Go de bande passante, 2 Go de stockage, 750K exécutions, 2 projets maximum, pause après une semaine d'inactivité), Pro à partir de 25 $/mois (2 To de bande passante, 150 Go de stockage, 10 $ de crédits de calcul base de données par mois), et Enterprise sur devis (SLA, support 24/7, SOC-2, HIPAA). Les dépassements sont affichés en clair : 15 $/100 Go de bande passante, 2,80 $/100 Go de stockage, 3 $/1 000 utilisateurs, 0,06 $/100K lectures, 0,10 $/100K écritures. Et pour qui veut du compute dédié à sa base, l'échelle grimpe de 10 $/mois (Micro) à 960 $/mois (4XL, 16 coeurs, 64 Go). Le discours commercial « un fournisseur, un abonnement, une facture » résume la stratégie : facturer le réseau, le pare-feu et le registrar au-dessus du backend.

Ce que la bête sait vraiment faire

Sous le capot, trois changements de fond. Le moteur passe sur Hyperloop B, un moteur à coroutines qui sert plusieurs requêtes concurrentes au lieu d'immobiliser un processus par requête ; côté auto-hébergement, l'instance par défaut tombe de 33 à 16 conteneurs parce que les files d'attente sont regroupées. La Console IV, reconstruite sur TanStack Start, embarque un terminal (la CLI dans le navigateur, déjà authentifiée) et un explorateur de requêtes construit depuis l'OpenAPI du projet. La couche données s'étoffe : VectorsDB (index HNSW, distance cosinus, produit scalaire ou euclidien), DocumentsDB (JSON sans schéma, ajouter un champ devient une écriture, pas une migration) et une Embeddings API sans service tiers. Le stockage expose une API compatible S3 (signature AWS V4, URL présignées), et un projet peut devenir fournisseur OAuth 2.1 / OpenID Connect. Côté agents, un serveur MCP hébergé expose quatre outils compacts et un catalogue interrogé à l'exécution, avec des intégrations documentées pour Claude Code, Codex, Cursor, VS Code, Zed, OpenCode, Grok Build et Zenflow. Face à Firebase (verrouillage propriétaire) et Supabase (narratif « Postgres d'abord »), Appwrite joue la carte du multi-moteur et de la souveraineté.

Les couleuvres à avaler

Première couleuvre : les nouveautés phares sont éteintes par défaut. VectorsDB, DocumentsDB, l'Embeddings API et la double écriture ClickHouse exigent de provisionner des moteurs supplémentaires puis d'activer des drapeaux (_APP_VECTORSDB, _APP_DOCUMENTSDB) avec un conteneur d'embeddings que l'éditeur lui-même décrit comme gourmand en ressources. Le récit « un backend RAG sans base vectorielle » se paie en heures d'exploitation. Deuxième : le PostgreSQL « par défaut » ne migre personne. Le défaut ne vaut que pour les installations neuves ; une instance existante garde son moteur, figé pour la vie de l'instance. Passer à Postgres, c'est réinstaller. Troisième : la montée de version est à étages il faut d'abord être en 1.9.6, et la route GET /v1/health/executions disparaît au passage, de quoi casser toute supervision qui la sonde. Quatrième : le self-hosted 2.0 est incomplet par construction, le pare-feu, l'API S3 et le journal d'activité étant d'abord cloud-only, « très bientôt ». Enfin, 990 issues ouvertes, aucun fil Hacker News dédié à la 2.0 (le plus gros reste celui de mars 2022), et une note agrégée sur 4 avis G2 : la croissance en étoiles ne dit rien du rythme d'adoption réel.

Verdict

Appwrite 2.0 est une vraie refonte, pas un coup de peinture. Pour l'auto-hébergeur qui accepte de provisionner ses moteurs et d'encaisser une migration à étages, c'est une plateforme solide, moins verrouillée que Firebase et plus multi-moteur que Supabase. Pour celui qui croyait déployer un backend RAG clé en main, ce sera une désillusion. Le positionnement agent-first est réel mais reste cloud-biaisé côté MCP. On aime, on surveille, on garde un oeil sur les 990 issues.

cas d'usage

  • 1. Prototyper un backend complet (auth, données, stockage) sans payer
  • 2. Auto-héberger un backend souverain pour un projet français
  • 3. Ajouter une couche RAG (VectorsDB + Embeddings) à une application existante
  • 4. Exposer un stockage compatible S3 et un fournisseur OAuth 2.1
  • 5. Brancher ses agents IA (Claude Code, Codex, Cursor) sur un backend via MCP

astuces

  • Activer VectorsDB et DocumentsDB via les drapeaux _APP_VECTORSDB et _APP_DOCUMENTSDB après avoir provisionné les moteurs
  • Pour passer à Postgres, partir d'une installation neuve : le moteur d'une instance existante est figé
  • Corriger la supervision avant la montée en 2.0 : la route GET /v1/health/executions disparaît