@chris.raroque: MISTAKE NO. 3/10 ✶ I chose the wrong database for my app 🥲 The number that made me regret Firebase wasn’t $115… It was 74 million. That’s how many database reads Ellie made in one 30-day window, even though fewer than 3,000 people used it each day. The video simplifies this a little, so here’s the nuance: Cloud Firestore is Firebase’s NoSQL document database. It scales automatically, and its real-time and offline support and flexible document model helped me ship Ellie quickly. But Ellie’s data became extremely connected. One task can belong to a list, have multiple labels, repeat on a schedule, be shared with someone, and connect to calendar data. In my current Firestore setup, those pieces live in separate documents and several live listeners keep them updated. Pulling everything together means lots of document reads, and Firestore charges for each one. My July Firestore read charges were $115.26. That isn’t catastrophic. The read count was the red flag 👀 If I rebuilt Ellie today, I’d probably start with Postgres through Supabase or Convex. A relational database is a more natural fit for heavily connected data because it can represent those relationships directly and combine related rows in one query. That doesn’t mean Firebase is bad or that NoSQL is always inefficient. I could probably improve my existing setup by restructuring documents, caching more, and reducing listeners. I also haven’t migrated Ellie, so I can’t honestly promise the exact savings. My mistake was choosing a database before I understood the questions my app would need to ask. My new rule: write down the five things your app will query most often before choosing a database. If those queries constantly combine connected data, seriously evaluate SQL. If real-time and offline sync are the product, Firestore may still be a great fit. Next mistake: I let my AI bill reach $700 before optimizing it 🥲 #softwaredeveloper #coding #appdevelopment

Chris Raroque

Open In TikTok:

Region: US

Saturday 22 August 2026 19:29:30 GMT