Aurabase vs Neon : Postgres toujours actif contre Postgres qui se met en veille
Aurabase provisionne une base PostgreSQL 16 dédiée par projet, active en permanence, hébergée en UE. Neon désolidarise compute et stockage et met le compute en veille dès que l'activité retombe — un choix pensé pour le développement jetable, pas pour un backend de production qui doit répondre à la première requête. Voici ce que ce choix change concrètement.
Aurabase : base Postgres 16 dédiée par projet, compute jamais suspendu, RLS native, NL2SQL/RAG intégrés, infrastructure vérifiée en Allemagne et en Finlande. Neon : compute qui scale à zéro et se réveille à la demande, racheté par Databricks (société américaine) en 2025, branching Copy-on-Write utile pour le développement. Si votre priorité est la disponibilité immédiate et la souveraineté juridique d'un backend de production, l'architecture Aurabase répond directement à ce besoin.
Un compute qui ne dort jamais
Aurabase provisionne une base Postgres 16 dédiée par projet, jamais partagée entre clients, sans compute suspendu à réveiller : votre backend répond dès la première requête, la nuit, le week-end, ou après une période creuse — sans latence de réveil à absorber.
Neon repose sur une architecture qui désolidarise compute et stockage et met le compute en veille par inactivité pour réduire la facture. C'est un choix cohérent pour un environnement de développement ou de test qui reste inactif la majeure partie du temps — mais chaque réveil introduit une latence de reprise que votre premier utilisateur du matin absorbe directement.
La question que le branching ne résout pas : où est votre société mère ?
Neon a été racheté par Databricks, société de droit américain, en 2025. Une société mère américaine reste exposée au CLOUD Act quelle que soit la région où tournent physiquement vos données — un mécanisme juridique indépendant de la géographie du serveur.
Aurabase SAS est une société de droit français, avec une infrastructure de production vérifiée entièrement en UE (Nuremberg, Falkenstein, Helsinki via Hetzner). Aucune case région à cocher pour compenser après coup : la nationalité du fournisseur et la localisation des données pointent dans la même direction dès le départ.
Lire l'article complet : pourquoi la nationalité du fournisseur compte plus que la région serveurCe que Neon fait mieux — et pourquoi ça ne suffit pas en production
Le branching Copy-on-Write de Neon crée une instance Postgres isolée en moins d'une seconde à partir d'un parent partagé — un vrai gain pour un environnement de prévisualisation par pull request. Aurabase n'a pas d'équivalent à ce jour.
Mais un backend de production ne se résume pas à des branches jetables : il lui faut de la RLS native pour l'isolation multi-tenant, du NL2SQL natif pour les fonctionnalités IA, et une disponibilité qui ne dépend pas d'un réveil de compute. C'est là que l'architecture Aurabase — Postgres dédié en permanence, RLS et IA natives dans le même cœur — répond à un besoin que le branching seul ne couvre pas.
Recherche et analytics natifs : un différenciateur étroit, pas une plateforme complète
Xata ajoute recherche plein texte, recherche vectorielle et analytics (via pg_cron et des vues matérialisées) directement sur Postgres, pour éviter d'assembler une pile OLAP séparée. C'est un positionnement de niche technique, pas un BaaS complet : pas d'auth intégrée, pas de temps réel, pas de fonctions edge.
Aurabase couvre nativement le pgvector, le RAG et le NL2SQL — plus large que la recherche/analytics de Xata — dans une plateforme qui inclut aussi auth, storage, temps réel et fonctions edge Rust/WASM. Voir notre tutoriel pipeline RAG avec pgvector.