Firebase & Realtime: What It Actually Is (And Why Many Devs Are Leaving)

I remember my first time with Firebase. I was building a small chat app for a college project. Started with MySQL + Express + polling every 5 seconds. It worked, but felt hacky - messages showed up delayed, and bandwidth was wasted. Then a friend recommended Firebase Realtime Database. Within an hour I deleted all my polling code, and messages appeared on the other screen without a refresh. That was my first "realtime" magic moment.

But after using it on 2 real projects, I realized: Firebase is powerful, but "realtime" doesn't mean it's the right fit for everything. And this blog? It's built with Supabase, not Firebase. Here's why.

---

What Firebase Actually Is

Firebase is a backend-as-a-service by Google (originally Firebase Inc., acquired in 2014). The pitch: you don't write your own backend. Install the SDK, and you instantly have:

• Database (Realtime Database or Firestore)
• Auth (Google/email/phone login)
• Storage (files/photos)
• Hosting
• Cloud Functions (similar to Supabase Edge Functions)
• Analytics, Push Notifications, Crashlytics, etc.

One platform, all your backend needs reduced to clicking around a dashboard. For small MVPs or personal projects, it genuinely saves time. I once shipped an internal polling app in 2 days using Firebase - the same thing took ~2 weeks with Express + Postgres.

---

What Does "Realtime" Mean?

This is the key part. Many people misunderstand it.

Realtime doesn't mean "fast." Realtime means: data changes sync to all connected clients automatically, without you re-requesting anything.

It works via WebSocket (or long-polling fallback). You subscribe to a database path, say messages/chat-room-1. Every time that path changes - add, edit, delete - Firebase pushes the new data to all subscribers.

Compared to traditional REST:

• REST: client asks "any new messages?" every 5 seconds → that's polling. Wasteful bandwidth, 5-second delay.
• Realtime: server says "here's a new message" the instant it arrives → that's push. Efficient, instant.

Simple pseudocode:

import { getDatabase, ref, onValue, push } from "firebase/database"

const db = getDatabase()
const roomRef = ref(db, "messages/chat-room-1")

// Subscribe: every change triggers the callback
onValue(roomRef, (snapshot) => {
console.log("data changed:", snapshot.val())
})

// On another client, write data:
push(roomRef, { text: "hi", user: "me" })
// → every subscriber instantly gets the event

onValue is a subscription. Any change triggers the callback. That's why chat apps become trivial - no need to set up your own WebSocket server.

---

When Firebase Realtime Makes Your Life Easy

1. Chat & messaging.

Classic use case. Subscribe to a room, the other person sends a message, it shows up. No socket.io, no WebSocket server to set up.

2. Collaborative apps.

Google Docs-style, realtime kanban boards, Figma-lite. Multiple people editing the same thing, changes sync instantly.

3. Live dashboards & presence.

"Who's online right now?" - Firebase has onDisconnect that automatically cleans up status when a user closes the tab. Building "user is typing..." indicators is easy too.

4. Lightweight multiplayer games.

Player positions sync. But for competitive games needing < 50ms latency, Firebase has too much overhead - use a custom WebSocket server (Go/Elixir) instead.

5. Rapid MVPs.

For side projects where you just need "data in, data appears on another screen" without thinking about infrastructure, Firebase is perfect.

---

But There's a Dark Side the Landing Page Doesn't Mention

1. Costs explode at scale.

Firebase offers a decent free tier. But once your app gets busy, the bill can spike unexpectedly. Why? You're charged per read/write operation, not per storage. One user opens a list of 1000 items = 1000 reads. Realtime listeners re-fetching on reconnect = more reads. I once saw a startup hit $2000/month with only 5000 users - because the database design was inefficient.

2. NoSQL becomes painful for complex queries.

Both Firestore and Realtime Database are NoSQL. You have to model data for queries, not model data naturally. Want to query "articles in category X, month Y, sorted by views"? You often need to duplicate data or build manual indexes. If you're used to SQL, this is a different mental model.

3. Hard vendor lock-in.

Your business logic is glued to the Firebase SDK. Want to move to Postgres + your own WebSockets? Rewrite almost the entire data layer. Auth via Firebase? Migrating user accounts is painful - you can't export password hashes directly.

4. Query limits.

Firestore: max 50 composite indexes (free), IN queries max 30 values. Realtime Database: only one filter level, no native WHERE a = X AND b = Y. For apps with relational data, this bites constantly.

5. Cloud Functions cold start.

Many complain about 3-5 second cold starts for rarely-invoked Cloud Functions. Use that for a payment webhook and users waiting 5 seconds = bad UX.

---

Why This Blog Uses Supabase, Not Firebase

Honest question. I compared both when starting this project.

| | Firebase | Supabase |
|---|---|---|
| Database | NoSQL (Firestore / RTDB) | PostgreSQL (relational, full SQL) |
| Realtime | Built-in, mature | Realtime via Logical Replication |
| Auth | Google, phone, etc | Email, Google OAuth, magic link |
| Self-host | ❌ Not possible | ✅ Yes (open source) |
| Vendor lock-in | High | Low (standard Postgres) |
| Pricing | Per read/write | Per resource (RAM/bandwidth) |
| Free tier | Decent | Decent too |

My reasons for choosing Supabase for this blog:

• Blog data is relational (articles have authors, categories, comments, affiliate links). SQL is far more natural for these queries.
• I want the ability to leave if Supabase raises prices or lacks features someday. With Postgres, I can pg_dump and move to another server.
• The blog doesn't need realtime sync (except comments, which I solve with simple 30-second polling).

But if I build a chat app or collab editor tomorrow, Firebase is still a strong option. Different tools for different problems.

---

When You SHOULD Use Firebase

• You're building chat / messaging and don't want to set up your own WebSocket server
• You need presence (who's online) fast
• You're building an MVP that must ship in 1 week
• Your team has no backend engineer, and frontend devs must handle everything
• Your app is NoSQL-friendly (hierarchical, document-oriented data)

When You Should NOT Use Firebase

• Your data is heavily relational (multi-join, transactions, constraints)
• You need complex queries with combined filters
• High read traffic could mean a huge bill (analytics dashboards, news feeds)
• You're thinking "maybe move to my own server later" - Firebase's lock-in is brutal
• You need full control over the database (Postgres extensions, custom functions, etc.)

---

An Honest Closing

Firebase is a powerful tool for a specific category (chat, collab, rapid MVP). But it's not a silver bullet. Its realtime feature is cool, but its NoSQL nature hurts when your data is relational. Its pricing model can surprise you, and its vendor lock-in is hard.

I've used Firebase for 2 projects (1 chat app, 1 small collab tool) - both fit. I didn't use it for this blog because the data is relational and I needed SQL.

Choose your tool based on the problem, not what's trending on Twitter. If you need realtime + NoSQL + fast deploy → Firebase. If you need SQL + control + portability → Supabase. If you need both → use Postgres + a realtime library yourself, and accept the complexity.