Do you need your own backend? Firebase vs a Node.js backend

Two ways to give an app a backend

Almost every app needs a backend. Something has to store accounts, hold data and check who is allowed to see it. The choice is who runs it.

A managed backend such as Firebase gives you ready-made services: a database, sign-in, file storage and serverless functions, all reached through SDKs from the app. You write rules and a little server code, and Google runs the machines. Your own backend is a server application you control. Mine are written in Node.js, which describes itself as an asynchronous, event-driven JavaScript runtime for building network applications, with a PostgreSQL database behind it. The app talks to an API I design, and that API decides everything.

Neither is better in general. They fail in different places, and that is what I look at when a client asks.

What Firebase gives you without writing a server

Cloud Firestore is Firebase's main database. Google describes it as a cloud-hosted NoSQL database that apps reach directly through native SDKs. Data lives in documents grouped into collections. Realtime listeners keep data in sync across devices, and Firestore caches the data an app is using so it keeps working offline. Access is controlled with Firebase Authentication and Firestore Security Rules.

Firebase Authentication covers sign-in with email and password, phone number by SMS, Google, Apple, Facebook, Twitter and GitHub, plus anonymous sign-in and custom systems. Cloud Functions runs your backend code in response to events or HTTPS requests, written in JavaScript, TypeScript or Python.

For a prototype, that is a lot of work you never do. A chat feature or a live order status is quick on Firestore. I like it for exactly that.

How Firebase billing is structured

Firebase has two plans. Spark costs nothing and needs no payment method. Blaze is pay as you go: it includes Spark's no-cost usage and then charges for what you use above it.

Spark has hard daily limits. For the Standard edition of Firestore, the pricing page lists 1 GiB stored, 50,000 reads a day, 20,000 writes a day and 20,000 deletes a day. That is plenty for testing and for many small apps. It is not a plan to run a busy business on.

• Cloud Functions: Firebase's own setup guide tells you to upgrade the project to Blaze before you deploy functions, and the pricing page shows Functions usage only under Blaze.
• Phone sign-in: not available on Spark; on Blaze it is billed per SMS sent.
• No cost on either plan: Cloud Messaging (push notifications), Analytics, Crashlytics, App Distribution and Performance Monitoring, among others.
• Cloud Storage for files: on Blaze, fees are based on usage volume.

Where a Node.js and PostgreSQL backend pays for itself

The trouble with a document database starts with questions like this one: which customers ordered more than twice last month, from which branch, handled by which driver? In Firestore, you plan your data around the screens you show. Questions nobody planned for get awkward. In PostgreSQL, that is one query.

PostgreSQL is an open source object-relational database, ACID-compliant since 2001, with transactions, foreign keys and other integrity constraints built in. For orders, payments, bookings and stock, I want the database itself refusing bad data. Not app code in five places.

Admin dashboards are the other reason. Staff need search, filters, exports, roles and an audit of who changed what. I build those against my own API, so the business rules sit in one place and both the app and the dashboard obey them. Integrations with an accounting system, an ERP or a courier also belong on a server you control.

The cost is real. A server and a database have to be hosted, updated and backed up every month the app is live, and someone has to look after them.

The decision table I use with clients

My rule of thumb: if the only person who ever looks at the data is the user who created it, start on Firebase. The moment staff need to work with that data across users, plan your own backend. I would not build an ordering or membership business on Firestore and hope to bolt reporting on later.

How Launch, Growth and Scale handle the backend

Launch ($999, up to 10 screens) connects to the APIs you need, which can be a managed backend such as Firebase. It suits an MVP, a booking app or a simple directory. Growth ($1,699, up to 25 screens) includes your own Node.js backend and PostgreSQL database, with admin tools for the basics. Scale ($2,500, up to 50 screens) adds a full admin dashboard, integrations and push notifications on that same backend.

An app with its own backend can still use Firebase Cloud Messaging for push notifications, which is no-cost on both Firebase plans. Hosting and any Firebase usage above the free limits are not included in the package price; you pay those providers directly. If you are unsure which side of the table you are on, send me the brief and I will tell you which package fits before you pay anything.