Aurabase vs Google Firebase
Firestore est un magasin NoSQL propriétaire à schéma implicite. Aurabase est Postgres 16 relationnel avec Row Level Security native. C’est la différence structurante qui détermine tout le reste de cette comparaison.
Firebase impose Firestore, un magasin NoSQL propriétaire sans jointures natives et sans posture RGPD/UE affichée. Aurabase propose un PostgreSQL 16 relationnel complet avec Row Level Security standard, une facturation prévisible basée sur les ressources plutôt que sur chaque lecture de document, et une infrastructure de production vérifiée en Allemagne et en Finlande, exploitée par une société de droit français.
Comparatif des fonctionnalités
| Critères | Aurabase | Google Firebase |
|---|---|---|
| Modèle de données | PostgreSQL 16 relationnel · jointures SQL, contraintes, transactions ACID · pgvector embarqué | Firestore NoSQL orienté documents/collections · pas de jointures natives · requêtes composées limitées |
| Verrouillage propriétaire | Standard SQL portable · export pg_dump/pg_restore vers n’importe quel Postgres · workspace Rust MIT | Format Firestore propriétaire · export limité à l’écosystème Google Cloud |
| Sécurité au niveau ligne | Row Level Security Postgres · syntaxe SQL standard, portable en cas de migration future | Firestore Security Rules · langage de règles propriétaire, non portable |
| Fonctions serveur | Deno/TypeScript (V8) et binaires Rust compilés en WASM, exécutés par un runtime Wasmtime réel | Cloud Functions for Firebase — runtime Node.js/Python managé par Google |
| Modèle de facturation | Tarifs basés sur les ressources allouées (RAM, CPU, Go) · pas de compteur par lecture/écriture | Facturation à l’opération (chaque lecture/écriture/suppression de document, plan Blaze) |
| Souveraineté & juridiction | Infrastructure de production vérifiée en Allemagne et en Finlande (Hetzner) · société mère de droit français | Propriété de Google LLC (société de droit américain) · soumis au CLOUD Act quelle que soit la région choisie |
| Temps réel | CDC Postgres natif sur NATS JetStream, avec filtres de colonnes côté serveur · WebSockets & SSE | Abonnements temps réel Firestore natifs (onSnapshot) |
| IA native (NL2SQL, RAG) | NL2SQL et RAG intégrés au backend · pgvector embarqué · 3 fournisseurs LLM natifs (OpenAI, Anthropic, Gemini) | Extensions Vertex AI côté GCP · configuration et facturation séparées |
Vous évaluez aussi Supabase ? Voir la comparaison Aurabase vs Supabase.
La puissance relationnelle contre la dette technique NoSQL
Firestore contraint les développeurs à dénormaliser leurs données. Ajouter une relation entre deux collections signifie dupliquer des champs à la main, avec un risque d’incohérence à chaque mise à jour.
Clés étrangères, jointures multi-tables optimisées par le planificateur de requêtes, contraintes d’unicité, agrégations SQL standard et recherche vectorielle pgvector pour l’IA.
Pas de requêtes d’agrégation simples sans index composites coûteux à maintenir. Les requêtes jointes n’existent pas : tout se recompose côté client.
Portabilité des données — un schéma Postgres s’exporte avec pg_dump vers n’importe quel serveur Postgres, sans transformation intermédiaire. Un export Firestore reste, lui, dans un format propriétaire pensé pour être réimporté dans Firestore ou dans un autre service Google Cloud.
Row Level Security Postgres contre Firestore Security Rules
Firestore utilise un langage de règles propriétaire — les Firestore Security Rules — pour décider qui peut lire ou écrire un document. Aurabase s’appuie sur la Row Level Security de PostgreSQL, un standard SQL directement dans le moteur de base de données.
La différence pratique : une policy RLS s’écrit en SQL (auth.uid(), auth.role()), se teste avec des requêtes SQL classiques, et reste portable vers n’importe quel Postgres. Les Security Rules Firestore utilisent une syntaxe dédiée, avec son propre simulateur de test, non réutilisable en dehors de l’écosystème Firebase.
Fonctions serveur — Edge Functions WASM contre Cloud Functions managées
Cloud Functions for Firebase tourne sur un runtime Node.js ou Python entièrement managé par Google. Aurabase propose deux runtimes : Deno/TypeScript (V8), proche de l’expérience Firebase, et des binaires compilés en Rust vers WebAssembly, exécutés par un runtime Wasmtime réel — une dépendance de production du service, pas un test interne.
Authentification — Firebase Auth contre 15 fournisseurs OAuth + OIDC
Firebase Auth couvre l’essentiel — email/mot de passe, liens magiques, une dizaine de fournisseurs fédérés (Google, Facebook, Apple, GitHub, Twitter, Microsoft, Yahoo, jeu anonyme) — géré depuis la console Firebase.
Le service Auth d’Aurabase couvre 15 fournisseurs OAuth nommés — Apple, Bitbucket, Discord, Facebook, Figma, GitHub, Google, Kakao, Microsoft, Notion, Snapchat, Spotify, Twitch, Twitter et Zoom — plus un nombre illimité de fournisseurs OIDC génériques par projet (convention oidc:<nom>, pour tout fournisseur d’identité à découverte OpenID Connect comme Okta), MFA TOTP et Magic Links.
Fini la peur des factures Firestore imprévisibles
Sur le plan Blaze de Firebase, une boucle mal maîtrisée dans une Cloud Function ou une requête cliente mal paginée peut déclencher des millions de lectures Firestore et générer une facture élevée en quelques heures — chaque lecture, écriture et suppression de document est comptée séparément.
- Facturation basée sur les ressources : vous payez pour du CPU, de la RAM et du stockage alloués, pas pour chaque ligne lue.
- Indexation Postgres incluse : créer un index B-Tree, GIN ou HNSW sur Aurabase n’augmente pas le coût unitaire de chaque requête.
- Quotas transparents : les paliers de consommation sont visibles dans la console Studio, sans surprise de facturation à l’opération.
Détail complet des paliers sur la grille tarifaire Aurabase.
Souveraineté et conformité — pourquoi Firebase ne défend pas ce terrain
Firebase ne publie aucune page de comparaison officielle vis-à-vis d’un concurrent, et Google n’endosse pas de posture RGPD/CLOUD Act dédiée pour Firebase. Ce terrain reste largement cédé aux comparatifs tiers.
L’infrastructure de production tourne en Allemagne (Nuremberg, Falkenstein) et en Finlande (Helsinki), chez Hetzner. Aurabase SAS, la société qui l’exploite, est une société de droit français basée à Paris.
Firebase appartient à Google LLC, société de droit américain. Choisir une région Firestore européenne ne change pas la nationalité de la société qui héberge vos données — elle reste soumise au CLOUD Act quelle que soit la région cochée.
Quand rester sur Firebase malgré tout
Firebase reste un choix défendable dans deux cas précis : une équipe déjà installée dans l’écosystème Google Cloud, avec des intégrations GCP existantes qu’il faudrait réécrire ; ou une application mobile pure, sans besoin de relations complexes entre entités, où le modèle document/collection suffit largement.
Le plan gratuit Spark de Firebase reste par ailleurs une porte d’entrée simple pour prototyper sans engagement. Le compromis apparaît quand le schéma se complexifie, ou que la conformité RGPD devient une exigence contractuelle plutôt qu’un détail secondaire.