Firebase Realtime Database Guide

Learn Firebase Realtime Database from scratch — setup, CRUD operations, real-time listeners, security rules. Includes a complete chat app build, plus honest coverage of limitations you need to know before committing to Firebase.

Firebase Realtime Database (RTDB) was Google's first real-time, cloud-hosted database — and it still powers massive apps today because of its dead-simple API and sub-100ms real-time sync. This guide shows you exactly how to use it with a real chat app project, and gives you the honest truth about its limitations so you can choose wisely.

What is Firebase Realtime Database?

Firebase RTDB is a NoSQL cloud database that stores data as a giant JSON tree. Unlike traditional databases, changes are pushed to all connected clients in milliseconds — no polling, no refresh needed. Perfect for chat apps, collaborative tools, live dashboards, and multiplayer games.

How Firebase RTDB Works

Client A(User A's phone)

Firebase RTDB(Google Cloud)

Client B(User B's laptop)

1 Write: "Hello!" to /messages

Persists data, broadcasts to all listeners

2 Push event to Client B (sub-100ms!)

UI updates instantly — no refresh

RTDB vs Firestore: Which Firebase DB Should You Use?

Firebase has TWO NoSQL databases. Knowing the difference saves you from an expensive migration later:

Firebase RTDB vs Firestore

⚡ Realtime Database

🌳Data model: One giant JSON tree

💫Latency: Sub-100ms sync

💰Pricing: Per-GB stored and downloaded

📊Queries: Very limited

📈Scale: ~200K concurrent connections/DB

🎯Best for: Chat, presence, live state

📚 Firestore

📁Data model: Collections + documents

⏱Latency: ~200-500ms

💰Pricing: Per operation (read/write/delete)

📊Queries: Rich (compound, ordering, indexing)

📈Scale: Virtually unlimited

🎯Best for: General-purpose apps, e-commerce

Setup: 5 Minutes to Your First Database

# 1. Go to https://console.firebase.google.com
# 2. Click "Add project" → name it "my-app"
# 3. In the left sidebar, click "Build" → "Realtime Database"
# 4. Click "Create Database" → choose region (us-central1) → "Start in test mode"
# 5. Your database URL appears: https://my-app-xxx.firebaseio.com

# Install Firebase SDK for your language:

# JavaScript / TypeScript (web, Node.js)
npm install firebase

# Python
pip install firebase-admin

# iOS: pod 'FirebaseDatabase'
# Android: implementation 'com.google.firebase:firebase-database:20.3.0'

Your First Write: Hello Firebase

// firebase-config.js
import { initializeApp } from "firebase/app";
import { getDatabase, ref, set, get, onValue, push, remove } from "firebase/database";

const firebaseConfig = {
  apiKey: "YOUR_API_KEY",
  authDomain: "my-app.firebaseapp.com",
  databaseURL: "https://my-app-xxx.firebaseio.com",
  projectId: "my-app",
};

const app = initializeApp(firebaseConfig);
const db = getDatabase(app);

// ── WRITE data ────────────────────────────────
await set(ref(db, "users/alice"), {
  name: "Alice",
  email: "alice@example.com",
  online: true,
});
// Data structure in Firebase:
// /users
//   /alice
//     name: "Alice"
//     email: "alice@example.com"
//     online: true

// ── READ data once ────────────────────────────
const snapshot = await get(ref(db, "users/alice"));
if (snapshot.exists()) {
  console.log(snapshot.val());  // { name: "Alice", email: ..., online: true }
}

// ── LIVE listen (the killer feature!) ─────────
onValue(ref(db, "users/alice"), (snapshot) => {
  const data = snapshot.val();
  console.log("User data changed:", data);
  // Triggers IMMEDIATELY whenever alice's data changes
  // From any client, anywhere in the world. No polling needed.
});

// ── PUSH (auto-generate unique key) ───────────
const newMessageRef = push(ref(db, "messages"));
await set(newMessageRef, {
  text: "Hello everyone!",
  sender: "alice",
  timestamp: Date.now(),
});
// Creates: /messages/-NvBcXyZ123/ with { text, sender, timestamp }

// ── DELETE ────────────────────────────────────
await remove(ref(db, "users/alice"));

Hands-On Project: Build a Real-Time Chat App

Let's build a working chat app using Firebase RTDB. Multiple users, messages appear instantly across all devices, online presence indicators — all in ~80 lines of code.

<!-- chat.html -->
<!DOCTYPE html>
<html>
<head>
  <title>Firebase Chat</title>
  <style>
    body { font-family: sans-serif; max-width: 600px; margin: 20px auto; }
    #messages { height: 400px; overflow-y: auto; border: 1px solid #ccc;
                padding: 10px; margin-bottom: 10px; }
    .message { padding: 8px; margin: 4px 0; background: #f0f0f0; border-radius: 6px; }
    .sender { font-weight: bold; color: #0078d4; }
    #online { color: green; font-size: 12px; }
    input, button { padding: 10px; font-size: 14px; }
    input { width: 400px; }
  </style>
</head>
<body>
  <h1>Live Chat</h1>
  <div id="online">Online: 0 users</div>
  <div id="messages"></div>
  <input id="input" placeholder="Type a message..." />
  <button id="send">Send</button>

  <script type="module">
    import { initializeApp } from "https://www.gstatic.com/firebasejs/10.7.0/firebase-app.js";
    import { getDatabase, ref, push, onChildAdded, onValue, set, onDisconnect }
      from "https://www.gstatic.com/firebasejs/10.7.0/firebase-database.js";

    const firebaseConfig = { /* your config */ };
    const app = initializeApp(firebaseConfig);
    const db = getDatabase(app);

    // Simple "login"
    const username = prompt("Your name:") || "Anonymous";
    const userId = Math.random().toString(36).substring(7);

    // ── Presence: mark user online, clean up when they disconnect ──
    const userStatusRef = ref(db, `status/${userId}`);
    set(userStatusRef, { username, online: true });
    onDisconnect(userStatusRef).remove();
    // When tab closes, network drops, etc — Firebase auto-removes this entry!

    // Count online users
    onValue(ref(db, "status"), (snapshot) => {
      const count = snapshot.size;
      document.getElementById("online").textContent = `Online: ${count} users`;
    });

    // ── Listen for new messages (real-time!) ──
    const messagesRef = ref(db, "messages");
    onChildAdded(messagesRef, (snapshot) => {
      const msg = snapshot.val();
      const div = document.createElement("div");
      div.className = "message";
      div.innerHTML = `<span class="sender">${msg.sender}:</span> ${msg.text}`;
      document.getElementById("messages").appendChild(div);
      document.getElementById("messages").scrollTop = 99999;
    });

    // ── Send message ──
    document.getElementById("send").onclick = async () => {
      const text = document.getElementById("input").value.trim();
      if (!text) return;
      await push(messagesRef, {
        sender: username,
        text: text,
        timestamp: Date.now(),
      });
      document.getElementById("input").value = "";
    };
  </script>
</body>
</html>

Open this HTML file in 2 browser tabs. Type a message in one tab — it appears in the other tab instantly. Close a tab — the online count updates automatically. This is Firebase's superpower.

Python Backend (firebase-admin)

# pip install firebase-admin
import firebase_admin
from firebase_admin import credentials, db

# Download service account JSON from Firebase Console:
# Project Settings → Service Accounts → Generate new private key
cred = credentials.Certificate("service-account.json")
firebase_admin.initialize_app(cred, {
    "databaseURL": "https://my-app-xxx.firebaseio.com"
})

# Reference a path
users_ref = db.reference("users")

# Write
users_ref.child("alice").set({
    "name": "Alice",
    "email": "alice@example.com",
})

# Read once
data = users_ref.child("alice").get()
print(data)  # {'name': 'Alice', 'email': 'alice@example.com'}

# Push (auto-generated unique ID)
new_order = db.reference("orders").push({
    "user_id": "alice",
    "total": 99.99,
    "created_at": {".sv": "timestamp"},  # Server-side timestamp
})
print(new_order.key)  # -NvBcXyZ123

# Update specific fields (doesn't overwrite siblings)
users_ref.child("alice").update({"last_seen": 1234567890})

# Delete
users_ref.child("alice").delete()

# Query (limited but useful)
recent = db.reference("messages").order_by_child("timestamp").limit_to_last(50).get()
# Returns the 50 most recent messages

Security Rules (CRITICAL — Don't Skip This!)

By default, Firebase "test mode" allows ANYONE on the internet to read and write your database. You MUST set security rules before going live.

// Firebase Console → Realtime Database → Rules tab

// ❌ DANGEROUS: Default "test mode" (public read/write)
{
  "rules": {
    ".read": true,
    ".write": true
  }
}
// Anyone can read/write ANY data. Your database will be pwned in hours.

// ✅ SECURE: Authenticated users only
{
  "rules": {
    ".read": "auth != null",
    ".write": "auth != null"
  }
}

// ✅ BETTER: User-scoped access
{
  "rules": {
    "users": {
      "$uid": {
        // Users can only read/write their own data
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    },
    "messages": {
      // Anyone authenticated can read messages
      ".read": "auth != null",
      // Users can only create messages as themselves
      "$messageId": {
        ".write": "auth != null && newData.child('sender').val() === auth.uid",
        ".validate": "newData.hasChildren(['sender', 'text', 'timestamp']) && newData.child('text').isString() && newData.child('text').val().length <= 1000"
      }
    }
  }
}

// Common security rule patterns:
// Admin-only write: ".write": "auth.token.admin === true"
// Read public data: ".read": true
// Validate data: ".validate": "newData.isString() && newData.val().length > 0"
// Owner only: ".read": "data.child('ownerId').val() === auth.uid"

The Advantages (Why Choose Firebase)

Zero server code for simple apps: Client talks directly to the database with security rules enforcing access. No backend needed for many use cases.
Real-time by default: Every query is reactive. Changes propagate to all clients in under 100ms.
Automatic offline support: SDK caches data locally. Your app works offline and syncs when reconnected. Perfect for mobile.
Presence detection: onDisconnect() handlers fire when a client goes offline — automatic cleanup.
Scales to millions of users: Google infrastructure handles the hard parts (replication, backups, availability).
Generous free tier: 1 GB storage, 10 GB/month download, 100 simultaneous connections — enough for real prototypes.
Integrated auth: Firebase Auth (Google, email, phone, Apple) works seamlessly with RTDB security rules.

The Limitations (Before You Commit!)

Firebase RTDB has serious limitations. Know them before building your business on it.

Firebase RTDB: Critical Limitations

1. No complex queries

Can order by ONE field only. No JOINs, no aggregations. If you need "orders where status=shipped AND total>100", use Firestore or PostgreSQL.

2. ~200K concurrent connections per database

Hard limit. You'll need multiple databases + a routing layer to scale beyond this. Most apps never hit it, but chat/presence apps can.

3. Entire database is one JSON tree

Must design data carefully. Deeply nested data means big downloads. Always "flatten" your data structure.

4. Per-GB pricing is costly at scale

\$5/GB downloaded adds up fast. A chat app with 100K daily users can cost \$500+/month. Cache aggressively.

5. Vendor lock-in

No SQL, no standard API. Migrating to PostgreSQL/MongoDB later requires rewriting all your database code. Plan accordingly.

6. Limited backups and exports

Daily backups only on Blaze plan. No point-in-time recovery. Scheduled exports to Cloud Storage needed for disaster recovery.

7. No server-side triggers within RTDB

Need Cloud Functions (separate service, cold starts, extra cost) for server logic like sending emails on new records.

Data Modeling: The #1 Thing People Get Wrong

# ❌ BAD: Deeply nested data
{
  "users": {
    "alice": {
      "name": "Alice",
      "posts": {
        "-NvPost1": { "title": "Hello", "comments": { "-NvCmt1": {...}, "-NvCmt2": {...} } },
        "-NvPost2": { ... }
      },
      "followers": { ... }
    }
  }
}
# Problem: Reading ONE user downloads ALL their posts, comments, followers!
# A user with 1000 posts = huge slow download every time.

# ✅ GOOD: Flat structure
{
  "users": {
    "alice": { "name": "Alice" }
  },
  "posts": {
    "-NvPost1": { "title": "Hello", "authorId": "alice" }
  },
  "comments": {
    "-NvCmt1": { "postId": "-NvPost1", "text": "Great!" }
  },
  "userPosts": {
    "alice": {
      "-NvPost1": true,
      "-NvPost2": true
    }
  }
}
# Now each query downloads only what you need.
# "userPosts" is an INDEX — quick lookup of a user's post IDs.

When NOT to Use Firebase RTDB

Complex queries needed — use Firestore or PostgreSQL
Financial/transactional data — lack of true ACID transactions across the tree is risky
Large datasets per user — per-GB pricing punishes data-heavy apps
Multi-tenant SaaS with strict isolation — security rules get complex fast
You need SQL — Firebase is NoSQL; accept that or choose differently

When Firebase RTDB Shines

Real-time chat and messaging — exactly what it was designed for
Collaborative editing (Google Docs style) — cursors, selections, presence
Live dashboards — metrics that update in real-time
Multiplayer games — game state sync across players
Presence and online status — onDisconnect() is magic
MVPs and prototypes — ship a working app in a weekend

The Verdict

Firebase Realtime Database is excellent for what it's designed for: small pieces of JSON data that need to sync in real-time across many clients. It's the fastest path to a working real-time app. But it's a specialized tool — not a general-purpose database. Use RTDB for chat, presence, and live state; use Firestore for everything else; use PostgreSQL/MongoDB when you outgrow both. Build fast, but architect with migration in mind.

Firebase Realtime Database: The Practical Guide with Real Project Examples