Answer at the top of each section, without detour. The sixteen questions cover what the term covers, how to seriously compare two platforms, and what Aurabase actually covers — checked in our code, not in our sales brochure. For a more detailed product FAQ (precise prices, authentication methods, storage quotas), the Aurabase product FAQ remains the reference.
The essentials
- A BaaS bundle of database, auth, storage and real time — a PaaS only provides the application runtime, without these ready-to-use building blocks.
- The first risk to check is not the displayed price but vendor lock-in: a proprietary data engine costs more to leave than a standard Postgres.
- For a project exposed to the GDPR or the CLOUD Act, the hosting region is not enough: the nationality of the parent company also matters.
- Aurabase bundles native auth, Postgres 16, real-time, storage, edge WASM and AI functions (NL2SQL, RAG) in eleven Rust services — verified in the repository, not in a slide.
- Migrating from Supabase does not affect the schema, RLS policies, or SDK — only the password must be reset (different hash).
Understanding backend as a service
What is a backend as a service (BaaS)?
A backend as a service is a platform that hosts and operates an application's server infrastructure — database, authentication, file storage, real-time, sometimes server functions — so that a team does not have to assemble or operate it themselves. The term refers to a managed service model, not a specific technology: two BaaS can rely on completely different data engines while claiming the same category.
What is the difference between BaaS and PaaS?
A PaaS (Platform as a Service, such as Railway or Render) provides an execution environment for your own server code: you write and deploy a complete backend yourself. A BaaS provides this backend directly — database, auth, and storage already exist, ready to call from a client SDK. The line has blurred in recent years, with some BaaS adding PaaS-style server functions, but the distinction remains useful for knowing how much infrastructure code you will need to write yourself.
Is a BaaS suitable for an app in production, or just for prototyping?
Both, provided that three points are checked before generalizing to production: are the line-level security (RLS) policies really applied on the server side, does the infrastructure scale without forced data migration, and is the data engine a portable standard or a proprietary format. A BaaS built on an open standard limits long-term risk, even in prototyping — you're not starting from scratch if the project grows.
Is a Postgres-based BaaS different from a proprietary NoSQL BaaS?
Yes, on a structuring point: portability. A Postgres schema can be dumped and restored with standard tools (pg_dump/pg_restore) to any Postgres host, including another BaaS. A proprietary NoSQL engine has no direct equivalent: the data structure and security rules are platform specific, making migration more expensive. This is not a judgment of technical quality, only a fact about the cost of release.
How to choose a BaaS
How to choose a backend as a service for your project?
Four criteria, in this practical order of priority: is the data engine portable or proprietary, are the security policies (RLS) applied on the server side or only documented, does the price scale with real usage or with arbitrary levels, and does the hosting correspond to your regulatory exposure (GDPR, CLOUD Act). A structured comparison table is better than an isolated opinion — we keep one up to date on the main alternatives in our BaaS 2026 choice grid.
Should we fear vendor lock-in with a BaaS?
The risk is real but unequal depending on the platforms. “Open source” alone is not enough to judge: a proprietary database remains a lock even if the server code is public. The two questions that really matter: can the data be exported in a standard format, and are the security policies written in a portable language (SQL) or in a platform-specific syntax. A Postgres backend with standard RLS policies reduces this risk structurally.
What questions should you ask about hosting and GDPR compliance before choosing?
Two distinct questions, often confused: where the data is physically hosted, and what is the nationality of the company operating the platform. Checking an “EU” region in an admin panel is not enough if the parent company remains subject to the US CLOUD Act — legal exposure depends on both, not just server geography. Ask for both answers in writing, not just a marketing badge.
Does the price of a BaaS really scale with actual usage?
It depends on the billing model, not on the BaaS category in general. Check if the tiers are based on real resources (storage, queries) or on arbitrary thresholds that force a tier change before you really need more capacity. A seemingly generous free plan may hide unpredictable costs beyond that — ask the price of the next tier before you start, not after.
Aurabase in practice
What does Aurabase actually cover (what services)?
Eleven Rust services (axum architecture) natively cover authentication, the Postgres database, real-time, file storage, edge functions in WebAssembly, notifications and AI (NL2SQL, RAG) — not an assembly of third-party services presented as a unified platform. The API remains PostgREST compatible by default, with pg_graphql available as an option per project for those who prefer GraphQL.
What database is Aurabase based on, and why Postgres rather than a proprietary NoSQL engine?
Postgres 16, in dedicated cluster per organization. This choice directly answers the question of lock-in: a Postgres diagram remains exportable with standard tools, unlike a proprietary engine. A MongoDB engine is available as a secondary option for teams that need it, but Postgres remains the default engine and best covered by our RLS policies.
Does Aurabase offer a free plan?
Yes — the Free tier includes 3 projects, 512 MB of database and 1 GB of storage, without a credit card. The Pro level (€25/month) goes up to 10 projects and 8 GB of base; the Team level (99 €/month) at 50 projects and 32 GB. Enterprise remains on quote, with dedicated cluster and SLA signed at 99.99%.
| Bearing | Price | Projects | Storage |
|---|---|---|---|
| Free | 0 € | 3 | 512 MB DB · 1 GB files |
| Pro | €25/month | 10 | 8 GB DB · 100 GB files |
| Team | €99/month | 50 | 32 GB DB · 1 TB files |
| Enterprise | On quote | Unlimited | Dedicated, tailor-made cluster |
Where is Aurabase data hosted?
In the EU, on the Hetzner infrastructure: Nuremberg and Falkenstein (Germany), Helsinki (Finland). No non-EU hosting on verified production infrastructure. The location of servers is a necessary but not sufficient condition for complete EU sovereignty — the nationality of the company operating the platform also matters.
Is Aurabase open source or self-hosting?
The core of the backend (Rust workspace) and the JavaScript SDK are published under the MIT license. The complete stack is also launched locally via Kubernetes / k3d, to evaluate or self-host without depending on the managed cloud. The JavaScript SDK is published on npm (@aurabase/aurabase-js and nine associated scoped packages); The Python and Dart SDKs exist in the repository but are not yet published on their official registries (PyPI, pub.dev) at the time of writing.
Does Aurabase offer native AI capabilities like NL2SQL or RAG?
Yes, natively — not as a third-party assembly added on top. NL2SQL (natural language question transformed into validated and bounded SQL) and RAG (vector search on pgvector) are part of the same aura-aiservice. Three LLM providers have a dedicated native client: OpenAI, Anthropic (Claude), Gemini. Mistral, Scaleway AI and Ollama remain accessible via OpenAI compatible mode, without their own native client.
“EU Sovereignty” means EU hosted infrastructure and parent company under French law (Aurabase SAS) — both conditions count for the CLOUD Act exhibition, not just the first.
Migration and alternatives
Is it easy to migrate from another BaaS to Aurabase?
From Supabase, yes — Postgres schema, RLS policies, SDK and storage/real-time API remain almost identical, a standard pg_dump/pg_restore is sufficient for the data. The only real point of friction: the password hashes differ (Argon2id at Aurabase, bcrypt at Supabase by default), so each user must redefine theirs once. From Firebase, the migration is structurally more cumbersome: the proprietary NoSQL engine has no direct equivalent in Postgres schema, the data must be modeled before importing it. The full details are in our migration guide Supabase → Aurabase.
How does Aurabase stack up against Supabase and Firebase?
Facing Supabase: a unified 100% Rust core rather than a heterogeneous stack assembled service by service (Elixir/Go/TypeScript/Node on the Supabase side), supplemented by an infrastructure verified in the EU. Against Firebase: standard and portable Postgres SQL rather than a proprietary NoSQL engine, with a GDPR/EU posture displayed as a content pillar in its own right. Detailed comparisons, table against table, are on our pages Aurabase vs Supabase and Aurabase vs Firebase.
Other questions?
This FAQ covers choosing a BaaS in general — the full product FAQ, cited above, answers detailed technical questions about Aurabase (authentication methods, edge functions, precise quotas). The exact details of each level (Free, Pro, Team, Enterprise) are on the page prices.