Firebase: a backend you do not have to build yet

TL;DR

• Firebase is a backend-as-a-service from Google: a datastore, authentication, file storage, static hosting, and realtime sync you rent rather than build, reached from your app through client SDKs instead of a server you run yourself.
• The sweet spot is an MVP, a realtime feature, or a small team that would rather spend its time on the product than on plumbing. For that, it is one of the quickest honest ways to get a real backend behind a real app.
• The tradeoffs are real and worth knowing up front: the data model shapes how your app can query, the query language is deliberately narrow, the usage-based bill can climb in ways that are hard to predict, and some teams eventually migrate to a more conventional backend.
• Security rules are not optional. They are the access-control layer between your database and the open internet, and misconfiguring them is the classic way a Firebase app leaks data it should not.
• We help teams decide whether Firebase fits, build on it when it does, and plan the move off it when they outgrow it. For current limits, prices, and feature details, go to the official Firebase documentation.

What Firebase actually is

Firebase is a collection of backend services you rent instead of building. In a conventional stack, you stand up a database, write an API in front of it, add an authentication system, wire up file storage, find somewhere to host the result, and keep all of it patched and running. Firebase hands you managed versions of those pieces and lets your app talk to several of them directly from the client, through software development kits for the web and for mobile. It is owned by Google and sits on the same infrastructure as Google Cloud, which matters later when we talk about where teams go when they outgrow it.

The pieces most teams reach for are a document datastore (Firebase offers two, a newer document database and an older realtime JSON store), an authentication service that handles email and password sign-in along with common identity providers, file storage for user uploads, static hosting served over a content delivery network, and serverless functions for the logic that cannot safely live on the client. The single feature that defines the platform, though, is realtime sync: your app can listen to a slice of the database and receive changes as they happen, without polling, which is why chat, collaborative tools, live dashboards, and presence features are the things Firebase is best known for.

The honest one-line summary is this. Firebase is a way to have a working backend on the first afternoon, before you have decided most of the things a backend usually forces you to decide. For the right project, that is a genuine advantage. For the wrong one, the decisions you skipped come back later. Both halves of that sentence are true, and the rest of this post is about telling them apart.

The sweet spot: MVPs, realtime, and small teams

Firebase is at its best when speed matters more than control and when the product is still finding its shape.

An MVP is the obvious case. When the point is to put something real in front of users this month and learn from it, the time you would spend building and operating a backend is time not spent on the thing you are actually testing. Firebase collapses that work. Authentication, a datastore, and hosting are configured rather than built, and a small team can ship a working product with a fraction of the backend effort a conventional stack demands. The Twelve-Factor App guidance treats backing services like databases and auth as attached resources you consume rather than operate, and Firebase is close to the purest expression of that idea: the backing services are someone else’s to run.

Realtime features are the second case, and here Firebase is not just convenient, it is genuinely good at something that is hard to build well yourself. Keeping many clients in sync with a shared, changing state, handling the dropped connections and the reconnects and the ordering, is real engineering. Firebase does it as a core capability, so a feature that would be a project on its own becomes a listener you attach to a query.

Small teams are the third case, and it is really the thread through the other two. A team without a dedicated operations person benefits most from not running servers, not patching databases, and not getting paged when a disk fills up. If your constraint is people rather than money, renting the plumbing is often the right trade. This is the same reason we wrote about Google Cloud for teams who would rather not run servers: the managed-service argument is strongest exactly when there is nobody spare to do the unmanaged version.

The data model shapes your app

Here is the first tradeoff, and it is the one teams feel most. Firebase’s main datastore is a document database, and a document database rewards a particular way of thinking that is different from the relational habits many developers bring to it.

In a relational database you model the data cleanly and let the query layer assemble it with joins at read time. In a document store you model around how the app reads, not around how the data relates, and you often duplicate data on purpose so that a screen can be served from a single query rather than stitched together from several. This is a reasonable and widely used approach, but it is a decision you are making early, and it quietly shapes what the app can do later. We have written separately about when a document database is the right call, and the reasoning there applies directly: the data model is not a detail you can defer, because changing it after you have built on it is expensive.

Querying is deliberately narrow

The querying constraints follow from the same place. Firebase’s query capabilities are intentionally limited compared with a general-purpose relational database. There are no arbitrary joins, aggregation is limited, and queries are designed to stay fast and cheap by making you declare the access patterns up front, sometimes through indexes you define yourself. That constraint is a feature when it keeps you on the fast path. It is a wall when your product grows a reporting screen, an admin view, or an analytics need that wants exactly the kind of ad hoc, cross-cutting query the datastore was built not to do. None of this is hidden; it is all in the documentation. But it is the kind of thing a team reads only after it has already modelled its data the wrong way for the question it now needs to ask.

Security rules are the backend you still have to think about

The part of Firebase that is easiest to underestimate is security. Because your app talks to the database directly from the client, there is no server in the middle quietly enforcing who is allowed to read and write what. That enforcement moves into Firebase’s security rules, a declarative layer you write to say which authenticated user can touch which data.

This is not a formality. Get the rules wrong and you have a database open to the internet, which is one of the more common ways Firebase projects leak data: a developer opens the rules up during development to move fast, and never closes them before launch. Broken access control is one of the top categories in the OWASP Top Ten, and Firebase hands that responsibility to you in a concentrated form. The reassuring part is that the rules are testable and reviewable like any other code, and treating them that way, with the same seriousness you would give an API’s authorization checks, is the whole discipline. The hard part is that it is yours to get right, and the convenience of client-direct access is exactly what makes the stakes high.

Cost at scale, and when it stops adding up

Firebase bills by usage: reads, writes, storage, bandwidth, and function invocations, roughly. For a small or early product this is friendly, because you pay close to nothing while you have close to no traffic. We are deliberately not quoting numbers here, because prices and free-tier limits change and the only honest source is the current pricing and docs. But the durable point stands regardless of the numbers: a usage-based bill tracks your success, and a data model that reads inefficiently, or a realtime listener that fires more often than it needs to, can turn into a cost line that grows faster than your revenue does. The bill is predictable only to the extent that you understand your own access patterns.

This connects to the hosting side too. Firebase Hosting serves static assets over a content delivery network, which is a fine way to deliver a fast front end, and the Core Web Vitals you would optimize for apply the same way they would anywhere. The point is that the front end is rarely where Firebase costs surprise you. The datastore usage is.

Where teams move on

Firebase has a ceiling, and it is worth naming honestly because pretending otherwise is how teams get stuck. The common exit points are a query you cannot express, a cost curve that no longer makes sense at your scale, a need for a relational model with real transactions across many entities, or a wish for more control over the backend than a managed platform gives. None of these mean Firebase was a mistake. Shipping an MVP fast and migrating later is a perfectly good plan, and often the right one. Because Firebase sits on Google’s infrastructure, one natural path is toward the more conventional building blocks of Google Cloud, though plenty of teams move elsewhere entirely. The move is real work, which is the actual cost of the early speed, and the time to think about it is before you are forced to, not during an incident.

Should you build on Firebase

The decision is less about Firebase and more about your project. If you are shipping an MVP, building a realtime feature, or running lean and want to spend your effort on the product rather than the plumbing, Firebase is one of the strongest options available and we would happily build on it. If you already know you need rich relational queries, heavy reporting, or tight control over the backend, it is worth being honest that you may be choosing a tool you will migrate away from, and planning for that from the start. The worst outcome is picking it by default, modelling your data without thinking about the query constraints, leaving the security rules open, and discovering all three at once under load.

That decision, and the build on either side of it, is what our custom tool builds are for. We help you work out whether a backend-as-a-service fits the thing you are making, build it properly on Firebase when it does, with security rules treated as real code, and tell you plainly when you would be better served by something else. If you want a product shipped on a backend you do not have to build yet, tell us what you are making and we will give you a straight answer about whether Firebase is the right place to put it.