Managed Postgres bundled with auth, storage, realtime and an auto-generated REST and client API.
Cost shape: Free tier for hobby projects, then a flat per-project fee plus usage for compute, storage and bandwidth.
Strengths
- ✓Real Postgres underneath, so extensions, SQL and standard tooling all apply.
- ✓Auth, storage and realtime included, which removes several vendor decisions at once.
- ✓Client libraries let simple apps query straight from the browser safely.
Tradeoffs
- ✗Querying from the client pushes authorization into policies that are easy to misconfigure.
- ✗The bundled services encourage coupling that is painful to untangle later.
- ✗Dashboard-driven changes can drift from what is in your migration files.
Serverless Postgres that separates storage from compute, so branches of your database work like branches of your code.
Cost shape: Free tier with limited storage and compute hours, then usage-based billing for compute time and stored data.
Strengths
- ✓Database branching gives every pull request a realistic copy of production data.
- ✓Compute scales to zero, so idle side projects cost almost nothing.
- ✓Plain Postgres wire protocol, so any existing driver or ORM connects unchanged.
Tradeoffs
- ✗Scale to zero means the first query after idle pays a cold start.
- ✗Storage and compute separation adds latency compared to a local disk.
- ✗It is only the database, so auth, storage and jobs stay your problem.
A reactive backend where you write TypeScript functions instead of SQL, and queries push updates to clients automatically.
Cost shape: Free tier for small projects, then a per-developer plan with usage-based function calls and storage.
Strengths
- ✓Queries are reactive by default, so live-updating UI needs no subscription plumbing.
- ✓Backend functions are TypeScript sharing types with the frontend end to end.
- ✓Transactions and scheduling are built in, so background jobs need no extra service.
Tradeoffs
- ✗Not SQL, so analytics tools and reporting stacks do not plug straight in.
- ✗The programming model is proprietary, making a later migration a rewrite.
- ✗Complex relational queries are more awkward than in a relational engine.
Managed MySQL built on Vitess, aimed at teams that expect serious scale and want schema changes without downtime.
Cost shape: Paid plans priced by cluster size and usage, positioned at production workloads rather than hobby projects.
Strengths
- ✓Non-blocking schema changes reviewed like code before they hit production.
- ✓Vitess sharding means the growth path to very large tables already exists.
- ✓Deploy requests give schema migrations an approval workflow teams actually follow.
Tradeoffs
- ✗Foreign key constraints were historically restricted, which shapes how you model data.
- ✗MySQL rather than Postgres, so Postgres-specific extensions and types are unavailable.
- ✗Priced for real workloads, so small projects subsidise capacity they never use.
SQLite as a hosted service, replicated to the edge, with the option of one small database per customer.
Cost shape: Generous free tier, then usage-based on rows read and written plus stored data.
Strengths
- ✓Database per tenant is cheap, which makes hard isolation between customers practical.
- ✓Edge replicas put reads physically close to the user.
- ✓SQLite semantics are simple and identical to what you run in tests locally.
Tradeoffs
- ✗SQLite has one writer, so write-heavy workloads hit a ceiling by design.
- ✗Fewer data types and functions than Postgres, so some modelling gets manual.
- ✗Managing thousands of small databases becomes its own operational surface.
Google's mobile-first backend with a document store, realtime sync, offline support and push notifications in one bundle.
Cost shape: Free Spark tier, then pay as you go priced mainly on document reads, writes and stored data.
Strengths
- ✓Offline persistence and conflict handling on mobile are genuinely solved problems here.
- ✓Push notifications, crash reporting and analytics come from the same console.
- ✓Realtime listeners make collaborative and chat-style features straightforward.
Tradeoffs
- ✗Document model punishes relational data, pushing you toward heavy denormalization.
- ✗Billing counts document reads, so a careless listener can cost real money.
- ✗Security rules are a separate language with their own testing story.
Pricing described qualitatively because published plans change often. Data checked 2026-08-23.
