Are there pitfalls to using only a remote database for a mobile app?

Question

My research indicates that the ideal database design is:

Mobile App -> Local Database -> Syncing -> Remote Database

using something like PouchDB to do the data replication/syncing.

But wouldn't it work just as well, if not better, to simply skip the Local Database step?

Mobile App -> REST API -> Remote Database

Note that I don't need offline capability and I will never need it. Rest assured, there will always be a data connection available.

FWIW, I'm using React Native, MySQL for the remote DB, and the data is very relational since every record uses every data field.

• Kain0_0: Never is a sticky word. If you will never be off-line then why not simply provide a website? Much easier to keep updated. A much lower bar for user entry (they do not actually have to have a login to their mobile store) And its quite clear to the user why your app is not working... they can't get to your website. Otherwise the pitfall is the user, they expect an app on their phone to work regardless of if they can connect to the remote database. Work itself is a bit wobbly, they would at least expect the screen they were looking at before to still work after a network disconnect.

Answer 1

The main problem with relying solely on a remote database is what happens if the remote database isn't available. Suddenly your app will stop working.

That may or may not be a problem, depending on the app, but generally people will expect things to keep working even if their network drops for a while, or indeed for an extended period.

For example an app we're working on here is used by people who often work in places where there is no reliable internet connection for them, so the app buffers up to several hours of work and when possible contacts the servers to synchronise.

And that's more the norm than the exception in my experience for non-trivial apps and applications, not just for ones running on smartphones and tablets.

• AimFireReady: I knew that loss of connection would be the obvious objection, but my preemptive strike was evidently not strong enough. If you were to look past that, are there any other major objections to my proposed structure?
• jwenting: @Mithrandir network reliability and possibly performance come to mind. And in some places maybe cost (getting better, but I can remember when data calls cost a LOT, so you'd minimise them).
• gnasher729: There is performance, and there is cost. For many users, mobile data access isn’t free. So if I have delays because my internet is slow, I’m not happy. If I have to pay extra charges because your app eats up my data allowance I’m very unhappy.