I’m building an iOS app that will use a pretty large database, but the data won’t change very often. I’m thinking of using a local data storage, probably SwiftData, mainly because it works well with SwiftUI and nice things like @Query. My plan is to pull the data once from Firebase, store it locally, and then only fetch updates later using something like a lastUpdated field.
What I’m not sure about is whether Firestore or Realtime Database is the better choice (if they are appropriate at all for this). Firestore charges per CRUD operation, while Realtime Database charges based on bandwidth and storage.
Also I am curious what is better option for importing/exporting data…
How do I decide which one makes more sense for this use case?
EDIT:
The one of the main reasons for having a local database is that the app will involve lots of searches, sorts, and different types of queries. So, I would say it doesn’t make sense to hit the online database every time for that
Just clarifying, how this is worded, your question is actually the “realtime database vs Firestore” because both of these part part of Firebase itself
I would recommend you do not do this. Firebase already stores data locally automatically for you and this isn’t necessary. And syncing local and cloud data is a huge headache and more trouble than it’s worth.
Which is why Firebase does this and solves it for you
Import and export from where to where?
It depends on how that data is filtered /sorted and in what way you mean. Like how much data is it, and is a user filtering / sorting multiple times in one session or will they close the app multiple times and open it again just to filter / sort
Firebase has an article that can help answer your question! But generally the recommendation is to use Firestore
At the end, I’ve decided to use Firebase Storage to load the entire database as a JSON file. Then I decode it into @Model objects (SwiftData) for use in the app. Since updates will happen rarely, perhaps every few weeks… I thought this approach might be a reasonable solution . Every few weeks I will send notification to the app, and do a silent update. Or I will just make a button, like “update database”. However, I’m still unsure if it’s the best idea.
Regarding your comment:
I would recommend you do not do this. Firebase already stores data locally automatically for you and this isn’t necessary.
I’m not entirely sure if Firebase Firestore would work for my use case. My concern is that it might trigger reads even when no data has changed. That’s mainly because I don’t fully understand how Firestore works yet. I’ll probably need to do more research to better understand how it handles caching and reads.
Import and export from where to where?
I meant importing data into Firebase Firestore from an external file, and exporting the Firestore database into a JSON format, for example.
It depends on how that data is filtered /sorted and in what way you mean. Like how much data is it, and is a user filtering / sorting multiple times in one session or will they close the app multiple times and open it again just to filter / sort
The expected usage would be a high volume of filtering and sorting across various criteria, which will likely occur frequently. I’m not sure whether users will keep the app open between sessions or close and reopen it some time later, for the next search/filter task
I’m still figuring things out, but I really don’t think it’s necessary to hit Firestore for every search or filter (cause as I said, database will be the same for weeks). Also user doesn’t interact with data in any way other than reading it.
This works! It’s a totally fine solution! I’ve done something similar before.
Given everything else you’ve said, I would do this a slightly different way. I’ll come back to this.
Technically yes, this would happen. But given the suggestion I have below, you could prevent some reads. But Firestore is definitely more for information that’s changed more often than yours is. So the realtime db, and how you’ve done it now could be better!
First, cause of how often your data is updated, which isn’t that often, you could use Firestore or Realtime database. And you’re concern to prevent unnecessary reads, there’s a few ways to do this.
Make a field called just version or versionNumber, and users, every time they open the app, you’ll read that one little value, check if they have an updated version if they do, that’s it, no need to read anymore, if not then you query for the new data which is in the realtime db.
Another way rather than version is by using a lastUpdatedDate and then doing the same thing
To continue doing exactly what you’re doing, but similarly implementing what I’ve done. Read the versionNumber from the realtime db and that also has a field called data which would point to a specific record in the Firebase Storage. So anyone can really have any version of the data at a time, and you can always go back to specific versions if you need to.
The 3rd way may be the best for you!
You can update the data silently in the background using push notifications, or have an update database button, (if you still want to read a version or last updated date). It’s really down to whether or not you want a user to know that they’re updating, or if it should “just happen?”
It all will work, it’s dependent on your app and goals. But really with the amount of data you have, until you have many thousands of users, Firebase Firestore or the realtime database will be free to use.
Filtering
so all of the solutions I mentioned is for downloading all your data at once, and you can store it locally using SwiftData. Given your use case I would store the data locally as opposed to using Firebase’s way, because while their’s does cache, it will query it more often, cause Firebase is more so built around apps that need more updated data more often. So it will cache it, but if and when there’s a signal, it will check for updated data. More info here around how caching works.
@mikaelacaron Hey, thanks for the detailed answer! I think I’ll stick with option 3 for now. The only downside I see right now is that the whole database is pretty much wide open to anyone with some technical knowledge, since it’s stored locally in a sqlite file. But oh well, maybe I’ll figure out a way around that too. I’m sure there’s a solution out there, but that’s a whole other topic. Really appreciate you taking the time to help!
I had several comments to your response but first one that then depends on how I answer the others
)