The Firestore Data Model — Designing for Real-Time performance and Future Migration
UdharPay · Technical Architecture · Database Design · Fintech · Development
4
Core Collections
Real-time
UI Sync
PostgreSQL
Migration Target
Cloud Fn
Reminder Writes
The Challenge
UdharPay's data model needed to support three things simultaneously:
- Real-time updates — when a reminder is sent, the UI updates instantly
- Complex queries — show all overdue entries across all customers for a business
- Clean migration path to PostgreSQL when scale justifies it
The challenge: Firestore's document model doesn't behave like SQL — designing for today while keeping tomorrow's migration clean required deliberate structure from day one.
Our Solution
- Businesses collection — Firebase Auth UID as document ID, making security rules simple and efficient
- Customers — subcollection of business document, keeping data physically co-located with its owner
- Ledger entries — root collection with businessId field, enabling the overdue dashboard query without deep nested collection group queries
- Reminders — subcollection of ledger entries, never written by the client — only by Cloud Functions
The migration path
When UdharPay migrates to PostgreSQL, the Firestore structure maps cleanly to: businesses table → customers table (FK to businesses) → ledger_entries (FK to customers) → reminders (FK to ledger_entries). Denormalized fields become unnecessary in the relational model. Minimal data transformation required.
The Result
Real-time
UI sync on reminder send
Clean
PostgreSQL migration path
0
Client-written reminders
A Firestore structure that supports all current query patterns, enables real-time UI updates, and maps cleanly to a future relational schema — with minimal data transformation when the migration eventually happens.
Tech Stack
FirebaseFirestoreCloud FunctionsPostgreSQL (future)
Project Info
Client
UdharPay
Industry
Technical Architecture · Database Design · Fintech
Timeline
Development
Live URL
https://udharpay.com ↗More Case Studies
