Skip to content

Firebase Realtime Database JSON tree

Design question 3: How is data organised and stored?

One JSON tree: keys, paths and nested values.

What it explains and when it is useful

Firebase Realtime Database stores all data as one large JSON tree. Every value has a path made of keys from the root, such as /roomStatus/P5/state. Apps listen to a path and receive updates in real time.

When to use it: Solutions that use Firebase Realtime Database, typically for live data: status boards, chat, multiplayer game state, presence.

Worked example

Illustrative: PracticePal is a fictional project used throughout this guide.

Alternative scenario. A live room-status board on screens outside the practice rooms, which updates the moment a student checks in. Realtime Database suits this because the screens listen to one small branch.

Firebase Realtime Database JSON tree for an alternative scenario: a live room-status board outside the practice rooms; every value sits at a path such as /roomStatus/P5/statestate: "free"until: 1793682000000P1state: "occupied"bookingId: "b2291"checkedInAt: 1793680500000P5roomStatusonline: trueP1: trueP5: trueroomscorridor-1displaysstudent: "u381"at: 1793680500000b2291checkins/ (root)Path of a value = the keys from the root, e.g. /roomStatus/P5/state → "occupied"
The JSON tree for a live room-status board.

Scroll sideways to see the whole diagram.

The same data as JSON:

{
  "roomStatus": {
    "P1": { "state": "free", "until": 1793682000000 },
    "P5": { "state": "occupied", "bookingId": "b2291", "checkedInAt": 1793680500000 }
  },
  "displays": { "corridor-1": { "online": true, "rooms": { "P1": true, "P5": true } } },
  "checkins": { "b2291": { "student": "u381", "at": 1793680500000 } }
}

Notation and legend

Symbol or partMeaning
Rounded boxA key with children (a branch)
Square boxA leaf: key and value
LinesNesting: each step adds a key to the path
Path/key/key/key identifies one value
Numbers like 1793680500000Timestamps in milliseconds (Firebase convention)

Design decisions it communicates

A diagram earns marks when you explain the decisions it shows. In PracticePal's documentation these would each be one sentence:

  • The tree is kept shallow: each display listens to /roomStatus only, not the whole database.
  • Rooms a display shows are stored as keys with true values, which is the Realtime Database way to store a set.
  • Check-ins are keyed by booking ID so a duplicate check-in overwrites rather than adds.

Common mistakes

  • Deep nesting, so reading one value downloads a huge branch.
  • Arrays with numeric indexes instead of keyed objects.
  • Drawing collections and documents (that is Firestore).
Often confused with: Firestore diagram. Realtime Database: one tree, paths, listeners. Firestore: collections of documents, queries, subcollections.

Checklist for your own version

Ticks are saved in this browser only, so you can use the list while you draft.