Why I Stopped Using Databases for My Mobile Apps

When I started building MemoryStub — a mobile app that transforms photos into keepsake cards — my first instinct was to reach for a backend. That's what you do, right? You have data, you need to store it, so you set up a database.

Three weeks in, I scrapped the entire backend. Not because it was broken, but because I realized I was solving a problem I hadn't actually created yet.

The Sync Problem Nobody Mentions

When your app lives on someone's phone and also talks to a server, you have to make a decision every single time the user opens it: what is the source of truth?

Is it what's on the device? Or what's on the server? What happens when they conflict? What if the user is offline? What if they installed the app on a new phone? Do you overwrite local changes with server data, or the other way around?

The sync problem is not a technical challenge you solve once. It is a decision that quietly shapes every feature you build afterward. Choose carefully before you build anything else.

For MemoryStub, I was building a personal memory app. The data is deeply personal — photos, dates, private notes. The user doesn't want it on a server they don't control. And I don't want to run that server, pay for it, or be responsible for what's on it.

AsyncStorage Is Not a Compromise

I switched to AsyncStorage in React Native. On paper this sounds like a step down. In practice, for an app like this, it's the right tool.

Zero network requests on startup. The app opens instantly.
Works completely offline by default — no loading spinners waiting for data.
User owns their data. Full stop.
No backend to maintain, no cloud bill, no auth tokens to manage.

The trade-off is obvious: no cross-device sync, no account system, no server-side search. For MemoryStub, none of those were requirements. The app is a personal keepsake tool, not a collaborative platform.

When This Doesn't Apply

I'm not saying remote databases are wrong. My Restaurant Booking System needs a PostgreSQL backend — it has multiple users, roles, and real-time booking conflicts that require a central source of truth. That's what a database is for.

But I've noticed a pattern in how developers (including me, earlier) think: if you're building an app, you build a backend. It's almost reflexive. The question worth asking first is: does this data actually need to leave the device?

What I'd Do Differently

If I started MemoryStub today, I'd still go local-first. But I'd structure the local storage more carefully from day one — namespacing keys properly and building a thin data-access layer so if the app ever grew to need sync, swapping AsyncStorage for a synced store wouldn't mean rewriting half the codebase.

Architecture decisions compound. Make them with the future in mind, even when you're building something small.