# Rtdb Data Model

> Model Realtime Database structures — flat paths, fan-out writes, index tables, denormalized summaries, .indexOn. Use when the user designs an RTDB tree, complains about slow/overlarge RTDB reads, or asks how to shape data for RTDB queries.

- Skill: `davideast/rtdb-data-model` (Agent Skill)
- Install (CLI): `npx skillmds@latest add davideast/rtdb-data-model`
- Raw SKILL.md: https://api.skillmd.com/api/skills/davideast/rtdb-data-model/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: davideast (https://skillmd.com/u/davideast)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/davideast/rtdb-data-model

---


# RTDB Data Modeling

RTDB is one JSON tree; every path is an API endpoint and reading a path
downloads everything below it. Structure determines security, performance,
pagination, and query shape — so design paths around the reads.

## Steps

1. **Inventory the reads.** For each screen or listener: which entities, what
   order, what filters, how many items. Complete when every read is listed
   with its expected payload size.

2. **Survey existing data** (when a database exists). `rtdb_crawl_structure`
   maps the tree; the Realtime Database SDK's `get` samples nodes. Complete
   when current shape and sizes are known.

3. **Design paths around the reads.** Defaults that work:
   - Top-level flat entity collections (`/users`, `/posts`, `/postSummaries`)
     — never nest one entity type inside another.
   - Index tables for reverse lookups (`/userGroups/$uid/$groupId: true`).
   - Denormalized summary nodes sized for list screens; detail nodes fetched
     per item.
   - Push IDs for append-only lists (chronologically sortable, no collisions).

   Complete when every inventoried read is served by one path whose full
   payload is what the screen needs.

4. **Plan writes for duplicated data.** Every denormalized copy gets a
   multi-path fan-out write: a single call to the Realtime Database SDK's
   `update` with several full paths as keys updates all copies atomically.
   Complete when each duplicated field lists the paths one logical write
   touches.

5. **Declare query indexes.** Add `.indexOn` in the security rules for every
   child key used with `orderByChild`. Complete when each ordered/filtered
   read has a matching `.indexOn`.

6. **State the rules implications.** Flat top-level collections let each
   entity type carry its own access rule; index tables let membership gate
   reads. Hand the path map to the rules work (see the `rtdb-security-rules`
   skill). Complete when each path names who may read/write it.

7. **Seed and prove.** Write representative data with the Realtime Database
   SDK's `set`, `push`, and `update`, then read each inventoried path back
   with `get` and confirm the payload matches step 1. Complete when reads
   return exactly the modeled shape.

## Reference — anti-patterns

- Deep nesting under users or entities — one read drags the subtree.
- God nodes every client reads — fan-out hot spot and privacy hazard.
- Arrays with sequential numeric keys — concurrent writers collide; use push
  IDs.
- SQL-style normalization requiring client-side joins — duplicate instead.
- Multi-field filtering with no query-shaped path — RTDB queries take one
  `orderBy`; precompute composite keys (`"lang_level": "en_5"`) or restructure.