Choose Firebase when
- You are building a real product that needs realtime UI, offline sync, or mobile SDKs.
- You need per-user access control enforced by the database.
- You expect scale, and vendor lock-in is a price you accept for the platform.
TmpState vs Firebase (Firestore)
Firebase is Google's application-development platform. Firestore gives you a production document database with realtime listeners, offline sync, security rules, and deep integration with Firebase Auth, Functions, and Hosting. It scales from hobby apps to very large products.
The honest verdict
These tools are not really competitors, and pretending otherwise would be dishonest. Firebase is a production platform you adopt; TmpState is a database you grab. The real question is sequencing: for the first day of a prototype, Firebase costs you a Google account, a project, an SDK, and config plumbing before the first write, while TmpState costs one curl. For the first year of a product, Firebase gives you realtime, auth, rules, and scale that TmpState deliberately does not have.
Side by side
| Dimension | TmpState | Firebase |
|---|---|---|
| Time to first write | Seconds: curl tmpstate.dev, then POST JSON. | Minutes to hours: Google account, project, app registration, SDK install, config keys. |
| Setup artifacts | One URL to keep server-side. | SDK dependency, config object, service accounts, security rules to write. |
| Realtime | None. Poll or refetch. | First-class: live listeners with offline sync are the whole point. |
| Auth and access rules | None. The URL is the credential; capability-URL possession model. | Firebase Auth plus per-document security rules; production-grade. |
| Query power | List with cursor pagination; filter client-side or in your API route. | Indexed queries, compound filters, aggregation, vector search. |
| Scale ceiling | Deliberately capped quotas (docs, writes, doc size), even on Pro. | Effectively unlimited with a bill to match. |
| Lifetime and cost of an idle experiment | Expires free in 24h; nothing to remember to clean up. | The project lives in the console forever; the tenth abandoned project is where config sprawl lives. |
| Agent readiness | Self-onboarding via llms.txt, OpenAPI, MCP; no human step. | A human must create the project and hand credentials to the agent. |
Choose TmpState when
- It is day one of the idea and provisioning would cost more than the prototype.
- An agent is wiring the app and should not hold your Google credentials.
- The data is disposable by nature: demo, hackathon, workshop, QA repro.
- You want to defer the platform decision until the idea earns it.
When NOT to use TmpState here
An honest comparison argues against us too. Skip TmpState if any of these apply:
- Do not ship a consumer app on TmpState: no realtime, no auth rules, no SLAs.
- Do not model complex relational or heavily-queried data here; there is no query language.
- A public browser app that embeds the raw database URL exposes all its data.
Common questions
Can I start on TmpState and move to Firebase later?
Yes, and that is the intended path when a prototype graduates: GET $DB/__export returns the full database as JSON, and the REST-shaped access pattern ports to any document store.
Is TmpState cheaper than Firebase?
For always-on small databases, usually: Pro is $8/mo for 3 databases. Firebase's free tier is generous but the platform's cost model starts mattering as usage grows. For pure prototyping both are effectively free; TmpState is just faster to reach.
Try the ten-second version
The fastest way to compare is to create a database right now. No signup; it expires on its own.