React Native Database Guide: SQLite vs Realm vs WatermelonDB vs AsyncStorage

Overview

React Native teams often start local storage decisions too late. A project begins with a few saved settings, then adds cached API responses, then offline forms, then search, then background sync, and suddenly the original storage choice starts to feel fragile. The best time to compare options is before that friction becomes expensive.

At a high level, these four options solve different problems:

• AsyncStorage is best understood as a simple persistent key-value layer. It works well for preferences, tokens, feature flags, and small pieces of app state that do not require relational queries.
• SQLite gives you a familiar relational database model with tables, indexes, and SQL queries. It is a strong fit when your data is structured, query-heavy, or needs predictable control.
• Realm is an object database designed to feel closer to application models than raw SQL. It can be appealing when you want local persistence with a more model-driven developer experience.
• WatermelonDB is designed for larger offline-first applications that need high performance on mobile devices and a clear synchronization story at the app architecture level.

If you only need to persist a small amount of state, using a full database can be unnecessary. If you need complex local search, many records, or robust offline workflows, key-value storage will usually become a limitation. That basic split is the fastest way to narrow the field.

Another useful framing is this: AsyncStorage is storage, SQLite is a database engine, Realm is a local object database, and WatermelonDB is more of an offline-first data layer built on top of a database approach. They overlap, but they do not occupy the exact same level of abstraction.

For teams building within the Expo ecosystem, compatibility and setup complexity also matter. If you are still deciding on the broader stack, it is worth pairing this article with Expo vs Bare React Native: Which Stack Should You Choose for Your Next App?, because native module needs may influence the database choice earlier than expected.

How to compare options

The quickest way to avoid a poor fit is to compare these tools against real app requirements instead of feature checklists. Start with the following questions.

1. What kind of data are you storing?

If your app mainly stores booleans, strings, recent selections, and a few serialized objects, AsyncStorage may be enough. If you have entities like users, orders, carts, tasks, messages, or inventory items with relationships and filters, you are already in database territory.

2. How much querying do you need?

Querying is one of the biggest dividing lines. AsyncStorage does not give you native relational queries. You will likely end up loading blobs of JSON and filtering them in JavaScript, which can become slow and awkward as data grows. SQLite is strongest when query control matters. Realm offers a model-oriented path for querying local objects. WatermelonDB is designed for applications where local querying is part of the core experience.

3. Is offline support a convenience or a product requirement?

Some apps only need to survive a temporary disconnect. Others are offline-first by design. If users must create, edit, and search local data with confidence while disconnected, choose a solution that supports structured local persistence and a deliberate sync model. This is where WatermelonDB and some SQLite- or Realm-based architectures tend to make more sense than AsyncStorage.

4. What does sync look like?

No local database automatically solves synchronization. You still need conflict handling, retries, versioning, and decisions about which side wins during updates. WatermelonDB is often evaluated by teams specifically because sync is a first-class architectural concern. SQLite and Realm can absolutely support sync, but much of the policy and implementation remains your responsibility.

If your project also needs backend choices for auth and data APIs, a database decision often intersects with broader stack planning. Related guides on React Native authentication solutions and mobile backend options can help clarify how local storage fits into the full app architecture.

5. How sensitive are you to setup and maintenance overhead?

AsyncStorage is conceptually simple. SQLite can be straightforward if your team is already comfortable with SQL, but schema migrations and native integration still require discipline. Realm can reduce some boilerplate for model-centric teams. WatermelonDB may offer strong long-term structure for offline-heavy apps, but it usually asks for more up-front architectural commitment.

6. How important is Expo compatibility?

This should be checked early, not after implementation starts. React Native database choices can differ in how naturally they fit managed Expo workflows versus custom native builds. Because libraries and platform support evolve, treat this as a validation item in your evaluation process rather than a permanent assumption.

7. What are your team’s existing strengths?

A small team with strong SQL experience may move faster with SQLite than with an abstraction that hides the database. A product team focused on shipping offline forms and synced models may prefer a solution that gives clearer higher-level patterns. The best option is often the one your team can operate confidently six months from now, not the one that looks most elegant in a demo.

Feature-by-feature breakdown

This section compares the four options across the dimensions that most often shape production decisions.

Data model

AsyncStorage stores key-value pairs. You can serialize structured objects into JSON, but relationships and partial updates quickly become awkward.

SQLite uses a relational model. Tables, joins, indexes, and explicit schemas make it a natural choice for structured business data.

Realm centers on objects and schemas that map more directly to app models. Many teams like this because it feels closer to working with domain entities than writing SQL by hand.

WatermelonDB is built for local-first application data with models and query patterns designed around larger datasets and synchronization workflows.

Query power

AsyncStorage has minimal query capabilities. In practice, you fetch values by key and do transformation work in JavaScript.

SQLite is the most explicit and flexible here. If your app depends on filtering, sorting, aggregations, or relational access patterns, SQL remains hard to beat.

Realm offers structured querying within its object model. The experience can feel more ergonomic than raw SQL for certain teams, especially when the data model is app-centric.

WatermelonDB is intended for efficient local queries at scale and usually makes the most sense when local read performance is central to the UX.

Performance and scale

AsyncStorage is usually suitable for small, simple persistence needs. It is not the first choice for large collections or frequent query-heavy interactions.

SQLite has a long track record as an embedded database model and gives you direct control over schema design and indexing, which is useful when performance tuning matters.

Realm is often considered when teams want strong local database performance without managing as much SQL directly.

WatermelonDB is frequently evaluated for larger offline datasets and apps where responsiveness with many records is a top requirement.

Performance, however, is not just about the engine. It also depends on how much data you load into JavaScript, how often you re-render screens, and whether your sync strategy creates churn. Database choice is only one part of production stability and observability.

Offline support

AsyncStorage supports persistence while offline, but not a full offline-first data model. It is useful for caching or storing pending state, not for sophisticated local data behavior.

SQLite is a strong foundation for offline functionality if you are willing to design the storage and sync layers carefully.

Realm can be a good fit for local-first app flows where domain objects need to remain available and queryable without network access.

WatermelonDB stands out when offline capability is a core product requirement rather than a fallback behavior.

Sync complexity

AsyncStorage keeps sync simple only when your data needs are simple. As soon as you need conflict resolution or normalized records, complexity rises sharply.

SQLite gives you control, but that control means you own more decisions. You define sync payloads, local mutation queues, conflict policies, and migrations.

Realm may reduce some model friction, but syncing across devices still requires architecture, rules, and operational clarity.

WatermelonDB is usually considered by teams that already know sync is a major requirement and want a structure that acknowledges that reality from the start.

Developer experience

AsyncStorage is easy to understand and fast to start with. For simple apps, that matters.

SQLite offers clarity if your team likes SQL and explicit data access. It can feel lower-level, but also easier to reason about for complex data.

Realm can feel productive for teams who prefer working with objects and schemas rather than writing many SQL statements.

WatermelonDB may have a steeper learning curve, but it can pay off in apps that would otherwise accumulate ad hoc offline logic over time.

Migrations and long-term maintenance

All four options require forethought as the app evolves. AsyncStorage can become messy when JSON structures change across versions. SQLite migrations are explicit and disciplined. Realm and WatermelonDB also require schema evolution planning, just through different abstractions. The broader lesson: choose the tool whose maintenance model matches your team’s habits.

Testing and debugging

Simple key-value storage is easy to mock, but debugging logic built on top of serialized blobs can become surprisingly painful. SQLite is transparent if you are comfortable inspecting tables and queries. Realm and WatermelonDB can improve app-level structure, but you will want a clear testing strategy around model changes, data integrity, and sync edge cases. If your team is tightening overall quality workflows, pairing local storage choices with a review of React Native CI/CD tools is often worthwhile.

Best fit by scenario

If you want a short version, use this section as the decision map.

Choose AsyncStorage if…

• You only need persistent settings, lightweight caching, onboarding flags, or small session data.
• Your app does not require relational queries or large local datasets.
• You want the lowest conceptual overhead and understand that this is not a full react native database solution.

Common examples include theme preferences, dismissed banners, small drafts, and simple app configuration.

Choose SQLite if…

• You need structured local data with real queries.
• Your team is comfortable with SQL and wants direct control over schema and indexing.
• You are building search, filtering, reporting, or entity relationships into the app.

SQLite is often the practical middle ground: more capable than AsyncStorage, more explicit than object-database abstractions, and well suited to teams that prefer visible control.

Choose Realm if…

• You want local persistence that feels closer to working with app models and objects.
• You prefer not to hand-write as much SQL for day-to-day work.
• Your app has substantial local data needs but the team wants a higher-level developer experience.

Realm is often attractive for product teams that want a polished local database workflow without building every data access layer from scratch.

Choose WatermelonDB if…

• Your app is meaningfully offline-first.
• You expect larger local datasets and frequent local queries.
• Synchronization is part of the product architecture, not a later enhancement.

Think field apps, inventory tools, messaging-style local state, or business workflows where users need reliable local operations even with poor connectivity.

A practical shortlist for common app types

• Content app or simple SaaS client: Start with AsyncStorage for preferences and cache, move to SQLite or Realm only if structured offline data becomes important.
• Ecommerce app: AsyncStorage may cover cart fragments and preferences, but product caching, search, and order history often point toward SQLite or Realm as the app matures. If you are still shaping the app foundation, see best React Native starter kits and boilerplates.
• Field operations or offline forms: WatermelonDB or SQLite usually deserve early consideration.
• Admin or internal tool with heavy filtering: SQLite is often a strong fit because the query layer is central to usability.
• Prototype with uncertain requirements: Start small, but avoid storing core business entities in AsyncStorage if you already suspect the app will need robust local data later.

When to revisit

Your first storage choice does not need to be permanent, but changing it later can be disruptive. Revisit the decision when clear signals appear.

• Your data model changes shape: what began as simple preferences now includes records, relationships, or local search.
• Offline behavior becomes a product promise: users must create and edit data reliably without network access.
• Performance starts to slip: screens become slow because too much serialized data is loaded and filtered in JavaScript.
• Sync becomes complicated: you are building custom queues, retries, and conflict logic around a storage layer that was never meant for it.
• Expo or native setup constraints change: a new deployment plan, build system, or library requirement alters what is practical.
• The market changes: new React Native tools appear, old libraries lose momentum, or support expectations shift.

When you revisit, use a simple audit:

1. List every local data type in the app.
2. Mark each one as settings, cache, draft, transactional record, or synced entity.
3. Document the largest expected dataset and the screens that query it most heavily.
4. Write down your offline promise in one sentence.
5. Decide whether sync is optional, eventual, or mission-critical.
6. Validate current Expo and native compatibility before committing.

Then run a small proof of concept instead of debating abstractions. Build one realistic screen, one realistic query, one realistic write path, and one realistic sync edge case. That exercise usually exposes more truth than a long feature checklist.

For teams evaluating the full production stack, local storage should not be isolated from navigation, forms, analytics, crash reporting, and deployment. Related comparisons on React Native navigation libraries, form libraries, and crash reporting tools can help you make database choices that fit the rest of the app, not just one layer of it.

The durable takeaway is simple: use AsyncStorage for lightweight persistence, SQLite for structured control, Realm for object-centric local data, and WatermelonDB when offline-first architecture is central. If your app’s data needs are growing, revisit this topic before local storage decisions harden into product constraints.