What is Backend as a Service (BaaS)?
A cloud model where a provider runs the common backend pieces of an app (database, authentication, file storage, realtime updates, functions) and exposes them through SDKs and APIs, so you write little or no server code.
Definition
Backend as a Service (BaaS) is a cloud service model in which a provider operates the standard parts of an application backend for you and exposes them through client SDKs and HTTP APIs. Instead of writing and hosting your own server for sign-up, login, storing records, uploading files and pushing live updates, you call the provider's SDK from your web or mobile app, configure access rules in a dashboard or in code, and the provider runs the database, scaling, backups and security patches. A typical BaaS bundles: a managed database (document or relational), user authentication with email, magic links, OAuth social login and often multi-factor authentication, file or object storage, realtime subscriptions that push data changes to connected clients, serverless functions for custom logic, and usually hosting, push notifications or analytics. Access control is declared as rules that run on the provider's side, for example Firebase Security Rules or Postgres Row Level Security policies in Supabase, because the client talks to the backend directly. MBaaS, or mobile backend as a service, is the original name. The category grew around 2011 to 2013 with services such as Parse, Kinvey and StackMob that gave iOS and Android developers user accounts, data storage and push notifications without running servers. Facebook bought Parse in 2013 and shut the hosted service down in January 2017 after open-sourcing it as Parse Server, an early and much-cited lesson about depending on a single vendor. Today 'BaaS' and 'MBaaS' are used almost interchangeably, because the same platforms serve web, mobile and desktop clients. Backend as a service providers differ mainly in their data model and in whether you can run them yourself: Firebase (Google): Cloud Firestore and the Realtime Database (NoSQL document and JSON-tree stores), Firebase Authentication, Cloud Storage, Cloud Functions and Hosting. Proprietary and hosted only, with a local Emulator Suite for development. Supabase: open source and built on PostgreSQL. It generates a REST API from your schema with PostgREST, and adds Auth, Storage, Realtime and Edge Functions. Authorization is done with Row Level Security. Available hosted or self-hosted. Appwrite: open source and self-hostable with Docker, or used as Appwrite Cloud. Provides databases, auth, storage, functions and messaging behind one API with SDKs for many platforms. AWS Amplify: a framework and hosting service that wires your app to AWS services such as Cognito (auth), AppSync (GraphQL), DynamoDB, S3 and Lambda. In Amplify Gen 2 the backend is defined in TypeScript and deployed into your own AWS account. PocketBase: an open source backend shipped as a single Go executable with an embedded SQLite database, auth, file storage, realtime subscriptions and an admin dashboard. Ideal for small projects and prototypes; it is still pre-1.0, so upgrades can include breaking changes. BaaS vs PaaS vs serverless: a PaaS (Heroku, Render, Railway, Google App Engine) runs the backend code you write; you still design the API, the auth and the data layer, but you do not manage servers. Serverless or FaaS (AWS Lambda, Cloudflare Workers) runs individual functions you write, triggered by HTTP requests or events, and bills per invocation. BaaS goes one step further: the common backend features already exist and you mostly configure them. In practice the lines blur, since every major BaaS includes serverless functions for the logic its built-in features cannot express.
When to Use Backend as a Service (BaaS)
Reach for a BaaS when time to market matters more than backend control: MVPs, internal tools, hackathon projects, mobile apps with standard needs (accounts, profiles, feeds, chat, file uploads) and small teams without dedicated backend engineers. It removes weeks of plumbing and gives you auth and realtime features that are hard to build well. Be more cautious when you have complex domain logic or multi-step transactions that do not fit the provider's rules language, strict data-residency or compliance requirements, very high or spiky traffic where usage-based pricing (document reads, function invocations, egress) can climb quickly, or a need to run fully on your own infrastructure. Lock-in is the main trade-off. Proprietary data models and rule languages, such as Firestore's document structure and Security Rules, are expensive to migrate away from. Open source, standards-based options lower that risk: Supabase is ordinary Postgres you can dump with pg_dump, and Appwrite and PocketBase can be self-hosted. Whatever you choose, keep business logic in your own modules or functions rather than scattered across client code, write down your schema, and test an export early so a migration stays possible.
Backend as a Service (BaaS) in Practice
- Querying Supabase from a browser app with the JavaScript client. The anon key is public by design; Row Level Security policies on the table decide which rows this user may read: import { createClient } from '@supabase/supabase-js'; const supabase = createClient(process.env.NEXT_PUBLIC_SUPABASE_URL, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY); const { data, error } = await supabase.from('todos').select('id, title, done').order('id');
- The matching Postgres policy that makes that query safe. Without it, any visitor holding the public key could read every row: ALTER TABLE todos ENABLE ROW LEVEL SECURITY; CREATE POLICY "own todos" ON todos FOR SELECT USING (auth.uid() = user_id);
- Reading a Firestore document with the Firebase modular SDK (v9 and later): import { getFirestore, doc, getDoc } from 'firebase/firestore'; const db = getFirestore(app); const snap = await getDoc(doc(db, 'users', uid)); if (snap.exists()) console.log(snap.data());
- Running PocketBase locally: download the binary for your OS, then ./pocketbase serve The REST API is served at http://127.0.0.1:8090/api/ and the admin dashboard at http://127.0.0.1:8090/_/ with all data stored in the pb_data folder.
Common Mistakes
- Treating the public client key as the security boundary. In Firebase and Supabase the client config is meant to be visible; security comes from Security Rules or Row Level Security, and leaving those open exposes the whole database.
- Using a service-role or admin key in frontend code. Those keys bypass all rules and belong only on a server or in functions.
- Ignoring the pricing model. Chatty clients that re-read whole collections or open a listener per component can multiply document reads and turn a free-tier project into a large bill.
- Modelling relational data in a document store as if it were SQL, then needing joins and multi-document transactions the database handles poorly. Pick a Postgres-based BaaS if your data is highly relational.
- Assuming BaaS means no backend work at all. You still own the data model, access rules, migrations, backups policy and the custom logic that runs in functions.
- Not planning an exit. Without regular exports and documented schemas, leaving a provider after a price change or shutdown becomes a rewrite.