Firebase is fast to start and hard to leave — not because of a contract, but because your data model becomes theirs. AnyHost gives you standard Postgres, a container for your own backend, and the cache, storage, email and domains around it, in one account.
Free tier, no card. Postgres, Redis, storage, email and domains included · pricing
Firestore's model shapes how you store, query and denormalize everything. That's a fair trade while it fits. It stops being fair the day you need a join, a transaction across collections, an aggregate, or simply a second opinion on where your app runs — because by then the data model is the lock-in.
Security rules are their own language. Queries are shaped by Firestore's limits. Cloud Functions are the only server-side escape hatch.
Ordinary SQL, ordinary migrations, ordinary server code. Permission checks are an if in a language you already write.
If your app is realtime-first and offline-first — a chat client, a collaborative editor, a mobile app that must work on a train — Firebase's client SDKs do a genuinely hard thing well, and this page is not trying to talk you out of it.
Firebase wins four rows here, and three of them are the reason it exists. Read those first.
| Capability | Firebase | AnyHost |
|---|---|---|
| Database | Firestoreproprietary document store | Standard PostgresDATABASE_URL injected; pg_dump works exactly as you expect |
| Realtime sync and offline clients | Best in classthe reason many teams choose it | No |
| Hosted auth service | Yesbroad provider support | Noyou implement auth in your backend, or keep an auth provider |
| Mobile client SDKs | YesiOS, Android, Flutter | Noyour backend is an ordinary HTTP API |
| Push notifications | FCM | No |
| Runs your own backend code | Cloud Functionsrequest-scoped, cold starts | Container runtimebuilt from a pushed commit, stays running, health-checked |
| Managed cache / Redis | NoMemorystore via GCP, separately | First-partyencrypted, per-environment |
| Object storage | Yes | S3-compatibleprivate by default, optional public delivery path |
| Transactional email | Noextension or third party | Yescustom sending domain, delivery events, suppression |
| Separate dev and production state | Separate projectsmanaged by hand | By defaultevery project gets dev and prod with separate URLs, secrets and resources |
| Data portability | Export existsbut the model doesn't transfer | StandardPostgres dump plus a container image |
Firebase capabilities as documented publicly at the time of writing. AnyHost rows correspond one-to-one with our services page.
Builds from an immutable commit, structured failure reasons instead of a wall of log, health checks tied to the deployed URL, and redeploy to a known-good commit when a change goes wrong.
Dev and prod get separate URLs, separate secret sets and separate resources. Values are masked by default, and production mutations require explicit confirmation.
Postgres, Redis and object storage, each scoped to one project environment, with connection variables generated and injected rather than copied between consoles.
Global CDN, managed HTTPS, custom domains with DNS validation and apex support, and a public HTTPS smoke check after the cutover moves traffic.
Deployment evidence, runtime logs, health responses, and usage attributed down to project, environment and resource — readable by you or by your coding agent through the CLI.
Be honest with yourself about scope: leaving Firestore means reshaping documents into tables, and that is real work an agent will do with you rather than for you. Start with a read-only export and the dev environment. Your Firebase project keeps running throughout.
Fetch https://anyhost.app/agent-setup/prompt.md and follow it to set up Anyhost in this repository. Then plan a move off Firebase onto Anyhost. First map the Firestore collections to a relational schema and show me the plan before writing any code — I want to review the data model. Then provision Postgres, build the import, replace the client SDK calls with calls to our own backend running on Anyhost, and port the security rules into backend authorization checks. Work against the dev environment only. Ask me to confirm before anything touches production, and leave the Firebase project running.
Your agent will ask you before it changes anything in production — that confirmation boundary is enforced by the CLI, not just by the prompt.
More than leaving a SQL database, and you should assume it's the largest part of the move. Documents become tables, denormalized copies become joins, and security rules become authorization code. A coding agent makes it tractable, not trivial. If your app is small this is a weekend; if you have hundreds of collections it is not.
Two workable paths. Keep an external auth provider and have your AnyHost backend verify its tokens — least disruption, users don't notice. Or move to a library inside your own backend, which means a password reset cycle for anyone not using a social login. Neither requires you to change hosting again later.
Possibly, and we'd rather say so. If live sync and offline-first clients are the product, Firebase's SDKs solve something we don't. Teams in that position sometimes keep Firebase for the realtime surface and move the rest of the backend here.
Yes. Standard managed Postgres — your app gets DATABASE_URL injected, and humans get time-limited direct-access profiles that can be revoked. That's the whole point of this page: the thing you build on should be the thing you can take with you.
Free covers one development runtime with managed database, storage, CDN and email inside fixed limits, with no invoice. Pro is $20 per workspace per month and includes $20 of monthly infrastructure credit plus production environments, with pay-as-you-go beyond that. Full rates are on the pricing page, itemized per resource.
Start with the dev environment and a copy of your data. Your Firebase project keeps running until you decide otherwise.
Get the migration prompt