Local Data Persistence: SQLite, NoSQL, and Object Stores Compared

Choosing the right storage layer is critical for JavaScript applications that need to work offline or handle large datasets locally. The packages expo-sqlite, pouchdb, react-native-sqlite-storage, realm, and sqlite3 all solve this problem but target different environments and data models. Let's break down how they differ in practice.

🖥️ Environment Compatibility: Where They Run

The first decision is where your code runs. Some packages are built for mobile, others for servers, and some for both.

expo-sqlite is designed specifically for the Expo managed workflow.

• It works on iOS and Android through Expo modules.
• It does not require ejecting to bare workflow.

// expo-sqlite: Opening a database
import { useExpoSQLiteDatabase } from 'expo-sqlite';

const db = useExpoSQLiteDatabase('my.db');

pouchdb runs in browsers, Node.js, and React Native.

• It uses adapters to switch storage backends (e.g., IndexedDB, SQLite).
• Great for web apps that need mobile parity.

// pouchdb: Creating a database instance
import PouchDB from 'pouchdb';

const db = new PouchDB('my_database');

react-native-sqlite-storage targets bare React Native projects.

• It requires linking native iOS and Android code.
• Often struggles with new React Native architecture updates.

// react-native-sqlite-storage: Opening a database
import SQLite from 'react-native-sqlite-storage';

const db = SQLite.openDatabase({ name: 'my.db' });

realm works in React Native, Node.js, and Electron.

• It uses its own native engine instead of SQLite.
• Requires adding native dependencies to your project.

// realm: Opening a Realm
import Realm from 'realm';

const realm = new Realm({ schema: [PersonSchema] });

sqlite3 is strictly for Node.js and Electron.

• It relies on native C++ bindings compiled with node-gyp.
• Cannot run in a standard React Native JavaScript bridge.

// sqlite3: Opening a database in Node
import sqlite3 from 'sqlite3';

const db = new sqlite3.Database('my.db');

🗃️ Data Model: SQL vs JSON vs Objects

How you structure data changes significantly between these tools. Some use tables, others use documents or objects.

expo-sqlite uses standard relational tables.

• You define schemas with CREATE TABLE statements.
• Best for structured data with relationships.

// expo-sqlite: Creating a table
await db.execAsync(`
  CREATE TABLE IF NOT EXISTS users (
    id INTEGER PRIMARY KEY NOT NULL,
    name TEXT
  );
`);

pouchdb stores JSON documents.

• No fixed schema required.
• Each document has a unique _id.

// pouchdb: Saving a document
await db.put({
  _id: 'user1',
  name: 'Alice',
  role: 'admin'
});

react-native-sqlite-storage also uses relational tables.

• Syntax matches standard SQLite.
• Similar structure to expo-sqlite but different API.

// react-native-sqlite-storage: Creating a table
db.transaction(tx => {
  tx.executeSql(`
    CREATE TABLE IF NOT EXISTS users (
      id INTEGER PRIMARY KEY NOT NULL,
      name TEXT
    );
  `);
});

realm uses live objects based on schemas.

• You define classes or schema objects.
• Results update automatically when data changes.

// realm: Defining a schema
const PersonSchema = {
  name: 'Person',
  properties: {
    name: 'string',
    age: 'int'
  }
};

sqlite3 uses standard relational tables.

• Identical SQL syntax to expo-sqlite.
• Used primarily in server-side scripts.

// sqlite3: Creating a table
db.run(`
  CREATE TABLE IF NOT EXISTS users (
    id INTEGER PRIMARY KEY,
    name TEXT
  )
`);

🔍 Querying Data: Syntax and Experience

Reading data is where you spend most of your time. The experience ranges from raw SQL to object queries.

expo-sqlite uses async/await with SQL strings.

• Modern API feels like standard JavaScript.
• Returns rows as arrays or objects.

// expo-sqlite: Querying rows
const result = await db.getFirstAsync('SELECT * FROM users WHERE id = ?', [1]);

pouchdb uses map-reduce or Mango queries.

• Query by JSON selectors.
• Requires indexing for complex queries.

// pouchdb: Finding documents
const result = await db.find({
  selector: { name: 'Alice' }
});

react-native-sqlite-storage uses callback-based transactions.

• Older style requires nested functions.
• More verbose than modern async APIs.

// react-native-sqlite-storage: Querying rows
db.transaction(tx => {
  tx.executeSql('SELECT * FROM users', [], (tx, results) => {
    console.log(results.rows.item(0));
  });
});

realm uses object queries with filters.

• No SQL strings needed.
• Type-safe if using TypeScript.

// realm: Querying objects
const people = realm.objects('Person').filtered('age > 18');

sqlite3 uses callbacks or promises via wrappers.

• Native API is callback-based.
• Often wrapped by libraries like better-sqlite3 for sync usage.

// sqlite3: Querying rows
db.all('SELECT * FROM users', [], (err, rows) => {
  console.log(rows);
});

⚠️ Maintenance and Risk Assessment

Long-term support matters when your app grows. Some packages are stable, while others are fading.

expo-sqlite is actively maintained by the Expo team.

• Updates align with Expo SDK releases.
• Low risk for Expo users.

pouchdb has a long history and stable community.

• Maintenance is steady but slower than before.
• Still reliable for sync use cases.

react-native-sqlite-storage is effectively legacy.

• Updates are infrequent.
• High risk of breaking with new React Native versions.
• Do not start new projects with this.

realm is backed by MongoDB.

• Active development with cloud sync features.
• License changes have occurred, so check terms.

sqlite3 is the standard for Node.js.

• Very stable for server environments.
• Compilation issues can arise on different OS versions.

📊 Summary: Key Differences

💡 The Big Picture

expo-sqlite is the default choice for Expo developers. It removes native complexity while giving you full SQL power. Stick with this if you are in the managed workflow.

pouchdb shines when synchronization is the main goal. If you need to sync local data with a remote CouchDB instance without writing custom API endpoints, this is the tool.

react-native-sqlite-storage should be avoided in new work. It lacks the modern ergonomics and stability of expo-sqlite or realm. Migrating away from it is common in mature codebases.

realm is best for complex object graphs. If your data looks more like connected objects than rows in a table, Realm reduces boilerplate. The optional cloud sync is a major bonus for some teams.

sqlite3 belongs on the server or desktop. Use it for Node.js CLI tools or Electron apps. Do not try to force it into a mobile React Native build unless you have a very specific native module setup.

Final Thought: Match the database to your environment first. If you are on Expo, use expo-sqlite. If you need sync, look at pouchdb or realm. If you are on Node.js server, sqlite3 is the standard. Avoid legacy packages unless maintaining old code.