Use a proper database like Postgres or MySQL.
Firebase isn’t ideal for anything beyond simple data structures.
Use a proper database like Postgres or MySQL.
Firebase isn’t ideal for anything beyond simple data structures.
I’d suggest adding some kind of limit to your reads when needing to pull the whole database. Caching with something like React Query might help to avoid refetching already cached data.
The classic N+1 problem is happening here. The app pulls a list of 600 workers in one query but likely makes an extra query for each worker’s details. This adds up quickly—1 query for the full list plus 600 for individual details, which eats through the free tier limits. You should restructure the database to pull all necessary data in one query, for example, by storing roster details alongside each worker. Denormalizing is critical with Firebase since it’s best to store related data together. If needed, caching frequently accessed data locally can also minimize reads, and syncing updates can help reduce repeated queries.
@Cody
Why is the person retrieving all 600 records in the first place? They could enhance performance by using pagination.
If you’re using a useEffect function, make sure you include a dependency array; otherwise, you could end up with infinite loops of database reads, which will blow your allowance in no time. I learned that the hard way.
With all due respect, if you can’t figure out how to fix this issue, why are you being hired to build this web app?
You’ll likely make other critical mistakes that could wreck your dataset down the line, and that won’t be very pretty.
Does it really need to read the whole database, or can you narrow your query or cache the results?
How about just putting the entire database into a single record and only reading that record? Denormalization sounds like it might work for you. Just kidding!
Shaye said:
How about just putting the entire database into a single record and only reading that record? Denormalization sounds like it might work for you. Just kidding!
Sounds like a flat file system!
You could cache your results as JSON.
Sounds like you could use some help. It might be better to invest time in learning or share details like a repository for assistance.
How can I optimize database reads for a roster app.
I need to see your source code to really help here. Your code could either be flawed or your queries could be inefficient. If it’s a web app, you might want to try SQLite until you figure things out?
Would moving to DigitalOcean or another platform help with costs or efficiency?
No one can advise without seeing the actual problem first.
It’s like saying, “My car is acting strangely. I was told it’s the transmission. What do I do?”—it’s hard to provide guidance without more context.
Learn caching techniques.
Here are a few ideas:
If you’re seeing loops that waste valuable calls, consider batching queries with Firebase.
Forget Firebase and check out other platforms like instantdb.com. I haven’t tried them but they’re on my list to explore.
Since moving to DigitalOcean is on your mind, take a look at their managed database offerings as they might meet your needs.
You can optimize by only fetching necessary data with queries or caching frequently accessed info. Switching to a more scalable database might benefit you long-term, but first focus on optimizing your queries.
Consider adding indexes or separating read and write items with different tables.
This is probably a case of the N+1 problem.
Great advice here already.
You could drag the problematic code into something like Claude and ask it why it’s inefficient to learn and then request it to recode it.