Vengala Vinay

Having 12+ Years of Experience in Software Development

Home » React Native vs. Android Native: Local DB (SQLite, Realm) Sync Latencies under Thread Contention

React Native vs. Android Native: Local DB (SQLite, Realm) Sync Latencies under Thread Contention

Benchmarking Environment Setup

To accurately compare local database synchronization latencies between React Native and native Android under thread contention, a controlled benchmarking environment is crucial. This involves setting up identical data loads, concurrent operation patterns, and performance monitoring tools across both platforms. We’ll focus on SQLite and Realm as representative local database solutions.

For native Android, we’ll utilize the Android Studio profiling tools, specifically the CPU Profiler and Network Profiler (though network is less relevant for local DB sync, it’s good practice for overall app performance). For React Native, we’ll employ tools like Flipper with its React Native Debugger and Hermes Profiler, alongside custom timing instrumentation within the JavaScript and native modules.

Native Android: SQLite Synchronization Under Load

Native Android development offers direct access to the SQLite database via the Android SDK. For concurrent operations, managing threads and database access requires careful synchronization to prevent deadlocks and race conditions. We’ll simulate heavy read/write operations from multiple background threads.

Test Scenario: Concurrent Writes and Reads

Consider a scenario where 10 background threads are simultaneously performing inserts and updates on a table, while another 5 threads are performing reads from the same table. We’ll measure the average time taken for each operation and the number of failed operations (due to concurrency issues or timeouts).

SQLite Implementation (Java/Kotlin)

A common approach is to use a SQLiteOpenHelper and manage transactions. For concurrency, Android’s ContentProvider can offer some level of thread-safety, but direct database access from multiple threads requires explicit locking or using a single database connection managed by a pool or a singleton.

Here’s a simplified example demonstrating a single-threaded database access pattern, which is often enforced by SQLite itself on Android for write operations. To simulate concurrent access, we’d typically queue operations or use a dedicated background thread pool that serializes database access.

import android.content.ContentValues;
import android.content.Context;
import android.database.Cursor;
import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;
import android.util.Log;

import androidx.annotation.Nullable;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicLong;

public class ConcurrentDbManager {

    private static final String TAG = "ConcurrentDbManager";
    private static final String DB_NAME = "app_data.db";
    private static final int DB_VERSION = 1;
    private static final String TABLE_ITEMS = "items";
    private static final String COLUMN_ID = "id";
    private static final String COLUMN_VALUE = "value";

    private final ExecutorService dbExecutor = Executors.newSingleThreadExecutor(); // Enforces single-threaded DB access
    private final AtomicLong insertCounter = new AtomicLong(0);

    private static class DatabaseHelper extends SQLiteOpenHelper {
        DatabaseHelper(Context context) {
            super(context, DB_NAME, null, DB_VERSION);
        }

        @Override
        public void onCreate(SQLiteDatabase db) {
            String createTableQuery = "CREATE TABLE " + TABLE_ITEMS + " (" +
                                      COLUMN_ID + " INTEGER PRIMARY KEY AUTOINCREMENT, " +
                                      COLUMN_VALUE + " TEXT NOT NULL)";
            db.execSQL(createTableQuery);
        }

        @Override
        public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
            db.execSQL("DROP TABLE IF EXISTS " + TABLE_ITEMS);
            onCreate(db);
        }
    }

    private DatabaseHelper dbHelper;

    public ConcurrentDbManager(Context context) {
        dbHelper = new DatabaseHelper(context);
    }

    public void insertItem(String value, OperationCallback callback) {
        dbExecutor.execute(() -> {
            long startTime = System.nanoTime();
            SQLiteDatabase db = null;
            try {
                db = dbHelper.getWritableDatabase();
                db.beginTransaction();
                ContentValues values = new ContentValues();
                values.put(COLUMN_VALUE, value);
                long id = db.insert(TABLE_ITEMS, null, values);
                db.setTransactionSuccessful();
                long endTime = System.nanoTime();
                long duration = (endTime - startTime) / 1_000_000; // milliseconds
                insertCounter.incrementAndGet();
                Log.d(TAG, "Inserted item with ID: " + id + ", Duration: " + duration + "ms");
                callback.onSuccess(id, duration);
            } catch (Exception e) {
                Log.e(TAG, "Error inserting item", e);
                long endTime = System.nanoTime();
                long duration = (endTime - startTime) / 1_000_000;
                callback.onError(e, duration);
            } finally {
                if (db != null) {
                    try {
                        db.endTransaction();
                        db.close(); // Close after transaction
                    } catch (Exception e) {
                        Log.e(TAG, "Error closing DB", e);
                    }
                }
            }
        });
    }

    public void readItems(OperationCallback callback) {
        dbExecutor.execute(() -> {
            long startTime = System.nanoTime();
            SQLiteDatabase db = null;
            try {
                db = dbHelper.getReadableDatabase();
                Cursor cursor = db.query(TABLE_ITEMS, new String[]{COLUMN_ID, COLUMN_VALUE}, null, null, null, null, null);
                int count = cursor.getCount();
                long endTime = System.nanoTime();
                long duration = (endTime - startTime) / 1_000_000; // milliseconds
                Log.d(TAG, "Read " + count + " items. Duration: " + duration + "ms");
                callback.onSuccess(count, duration);
                cursor.close();
            } catch (Exception e) {
                Log.e(TAG, "Error reading items", e);
                long endTime = System.nanoTime();
                long duration = (endTime - startTime) / 1_000_000;
                callback.onError(e, duration);
            } finally {
                if (db != null) {
                    try {
                        db.close(); // Close after query
                    } catch (Exception e) {
                        Log.e(TAG, "Error closing DB", e);
                    }
                }
            }
        });
    }

    public interface OperationCallback {
        void onSuccess(long idOrCount, long duration);
        void onError(Exception e, long duration);
    }

    public void shutdown() {
        dbExecutor.shutdown();
    }
}

To simulate contention, we would launch multiple instances of these insertItem and readItems calls concurrently, all submitting tasks to the dbExecutor. The Executors.newSingleThreadExecutor() ensures that only one database operation (read or write) can execute at a time, effectively serializing access and demonstrating the queuing latency.

Performance Metrics

We’ll log the duration of each operation and count any exceptions. The primary metrics will be:

  • Average insert/update latency.
  • Average read latency.
  • Maximum insert/update latency (indicating peak contention).
  • Maximum read latency.
  • Number of database-related exceptions (e.g., SQLiteException, DatabaseLockedException).

Native Android: Realm Synchronization Under Load

Realm offers a different concurrency model. It’s designed for high-performance mobile databases and handles concurrency more gracefully than raw SQLite, especially with its object-oriented approach and live objects.

Test Scenario: Concurrent Writes and Reads

The same scenario of 10 concurrent writers and 5 concurrent readers will be applied to Realm. Realm’s architecture allows multiple threads to read concurrently, but writes are serialized. However, Realm’s write transactions are typically faster and more efficient than SQLite’s.

Realm Implementation (Java/Kotlin)

Realm instances are thread-confined. Each thread that needs to access Realm objects must obtain its own Realm instance. Writes are performed within executeTransaction blocks.

import android.content.Context;
import android.util.Log;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicLong;

import io.realm.Realm;
import io.realm.RealmConfiguration;
import io.realm.RealmObject;
import io.realm.annotations.PrimaryKey;
import io.realm.annotations.Required;

public class RealmDbManager {

    private static final String TAG = "RealmDbManager";
    private static final int THREAD_POOL_SIZE = 5; // For simulating concurrent operations

    private final ExecutorService executor = Executors.newFixedThreadPool(THREAD_POOL_SIZE);
    private final AtomicLong insertCounter = new AtomicLong(0);

    // Define Realm model
    public static class Item extends RealmObject {
        @PrimaryKey
        public long id;
        @Required
        public String value;
    }

    public RealmDbManager(Context context) {
        Realm.init(context);
        RealmConfiguration config = new RealmConfiguration.Builder()
                .name("app_realm.realm")
                .schemaVersion(1)
                .deleteRealmIfMigrationNeeded() // For simplicity in this example
                .build();
        Realm.setDefaultConfiguration(config);
    }

    public void insertItem(String value, OperationCallback callback) {
        executor.execute(() -> {
            long startTime = System.nanoTime();
            Realm realm = null;
            try {
                realm = Realm.getDefaultInstance();
                realm.executeTransaction(r -> {
                    Item newItem = r.createObject(Item.class, insertCounter.incrementAndGet());
                    newItem.value = value;
                });
                long endTime = System.nanoTime();
                long duration = (endTime - startTime) / 1_000_000; // milliseconds
                Log.d(TAG, "Inserted item. Duration: " + duration + "ms");
                callback.onSuccess(insertCounter.get(), duration);
            } catch (Exception e) {
                Log.e(TAG, "Error inserting item", e);
                long endTime = System.nanoTime();
                long duration = (endTime - startTime) / 1_000_000;
                callback.onError(e, duration);
            } finally {
                if (realm != null && !realm.isClosed()) {
                    realm.close();
                }
            }
        });
    }

    public void readItems(OperationCallback callback) {
        executor.execute(() -> {
            long startTime = System.nanoTime();
            Realm realm = null;
            try {
                realm = Realm.getDefaultInstance();
                long count = realm.where(Item.class).count();
                long endTime = System.nanoTime();
                long duration = (endTime - startTime) / 1_000_000; // milliseconds
                Log.d(TAG, "Read " + count + " items. Duration: " + duration + "ms");
                callback.onSuccess(count, duration);
            } catch (Exception e) {
                Log.e(TAG, "Error reading items", e);
                long endTime = System.nanoTime();
                long duration = (endTime - startTime) / 1_000_000;
                callback.onError(e, duration);
            } finally {
                if (realm != null && !realm.isClosed()) {
                    realm.close();
                }
            }
        });
    }

    public interface OperationCallback {
        void onSuccess(long idOrCount, long duration);
        void onError(Exception e, long duration);
    }

    public void shutdown() {
        executor.shutdown();
    }
}

In this Realm example, we use a FixedThreadPool to submit multiple operations concurrently. Realm’s internal mechanisms handle the serialization of write transactions. Reads can happen in parallel. The key is that each thread gets its own Realm instance.

Performance Metrics

Similar metrics as with SQLite will be collected:

  • Average insert latency.
  • Average read latency.
  • Maximum insert latency.
  • Maximum read latency.
  • Number of Realm-related exceptions (e.g., RealmException).

React Native: SQLite Synchronization Under Load

React Native’s SQLite integration typically relies on third-party libraries that bridge JavaScript to native SQLite implementations. Popular choices include react-native-sqlite-storage or expo-sqlite (for Expo projects). These libraries often abstract away much of the native threading complexity, but performance characteristics can vary.

Test Scenario: Concurrent Writes and Reads

We’ll simulate the same load: 10 concurrent write operations (inserts/updates) and 5 concurrent read operations. The challenge here is that JavaScript is single-threaded. All database operations are initiated from the JS thread and then handed off to native threads. The underlying native SQLite implementation will still enforce its own concurrency rules.

SQLite Implementation (React Native)

Using react-native-sqlite-storage, we can execute SQL statements. To achieve concurrency from the JS perspective, we’ll use Promise.all or async loops to fire off multiple requests. The library’s native module will queue these requests for the native SQLite driver.

import SQLite from 'react-native-sqlite-storage';
import { Platform } from 'react-native';

const DB_NAME = 'app_data.db';
const DB_LOCATION = Platform.OS === 'ios' ? `${SQLite.USER_DATABASE_PATH}/${DB_NAME}` : `/data/user/0/com.your_app_package_name/databases/${DB_NAME}`; // Adjust path for Android

let db = null;

const initializeDatabase = async () => {
    if (db) return db;
    try {
        db = await SQLite.openDatabase(
            DB_NAME,
            '1.0',
            'User Data',
            200000, // Size in bytes
            (dbInstance) => {
                console.log('Database opened successfully');
                // Create table if it doesn't exist
                dbInstance.transaction((tx) => {
                    tx.executeSql(
                        'CREATE TABLE IF NOT EXISTS items (id INTEGER PRIMARY KEY AUTOINCREMENT, value TEXT NOT NULL);',
                        [],
                        () => console.log('Table "items" created or already exists.'),
                        (error) => console.error('Error creating table:', error)
                    );
                });
            },
            (error) => {
                console.error('Error opening database:', error);
                throw error; // Re-throw to be caught by caller
            }
        );
        console.log('Database initialized');
        return db;
    } catch (error) {
        console.error('Failed to initialize database:', error);
        throw error;
    }
};

const insertItem = async (value) => {
    const startTime = performance.now();
    try {
        const dbInstance = await initializeDatabase();
        return new Promise((resolve, reject) => {
            dbInstance.transaction((tx) => {
                tx.executeSql(
                    'INSERT INTO items (value) VALUES (?);',
                    [value],
                    (tx, results) => {
                        const endTime = performance.now();
                        const duration = endTime - startTime;
                        console.log(`Inserted item. ID: ${results.insertId}, Duration: ${duration.toFixed(2)}ms`);
                        resolve({ id: results.insertId, duration });
                    },
                    (error) => {
                        const endTime = performance.now();
                        const duration = endTime - startTime;
                        console.error('Error inserting item:', error, `Duration: ${duration.toFixed(2)}ms`);
                        reject({ error, duration });
                    }
                );
            });
        });
    } catch (error) {
        const endTime = performance.now();
        const duration = endTime - startTime;
        console.error('Transaction error during insert:', error, `Duration: ${duration.toFixed(2)}ms`);
        throw { error, duration };
    }
};

const readItems = async () => {
    const startTime = performance.now();
    try {
        const dbInstance = await initializeDatabase();
        return new Promise((resolve, reject) => {
            dbInstance.transaction((tx) => {
                tx.executeSql(
                    'SELECT COUNT(*) as count FROM items;',
                    [],
                    (tx, results) => {
                        const endTime = performance.now();
                        const duration = endTime - startTime;
                        const count = results.rows.length > 0 ? results.rows.item(0).count : 0;
                        console.log(`Read ${count} items. Duration: ${duration.toFixed(2)}ms`);
                        resolve({ count, duration });
                    },
                    (error) => {
                        const endTime = performance.now();
                        const duration = endTime - startTime;
                        console.error('Error reading items:', error, `Duration: ${duration.toFixed(2)}ms`);
                        reject({ error, duration });
                    }
                );
            });
        });
    } catch (error) {
        const endTime = performance.now();
        const duration = endTime - startTime;
        console.error('Transaction error during read:', error, `Duration: ${duration.toFixed(2)}ms`);
        throw { error, duration };
    }
};

// Function to simulate concurrent operations
const simulateConcurrentOperations = async (numWrites, numReads) => {
    const writePromises = [];
    for (let i = 0; i < numWrites; i++) {
        writePromises.push(insertItem(`Value ${i + 1}`));
    }

    const readPromises = [];
    for (let i = 0; i < numReads; i++) {
        readPromises.push(readItems());
    }

    try {
        const results = await Promise.all([...writePromises, ...readPromises]);
        console.log(`Simulated ${numWrites} writes and ${numReads} reads. Total operations: ${results.length}`);
        return results;
    } catch (error) {
        console.error('An error occurred during concurrent operations:', error);
        throw error;
    }
};

// Example usage:
// initializeDatabase().then(() => {
//     simulateConcurrentOperations(10, 5);
// });

export { initializeDatabase, insertItem, readItems, simulateConcurrentOperations };

The react-native-sqlite-storage library uses a callback-based API, but we’ve wrapped it in Promises for easier async/await usage. The simulateConcurrentOperations function uses Promise.all to fire off multiple requests concurrently from the JavaScript thread. The underlying native implementation will handle the actual SQLite locking and queuing.

Performance Metrics

We’ll measure:

  • Average JavaScript execution time for insert/read operations (from performance.now() start to Promise resolution/rejection).
  • Number of JavaScript-level errors reported by the library.
  • Note: Direct measurement of native SQLite contention is harder from JS without custom native modules or advanced profiling.

React Native: Realm Synchronization Under Load

Realm provides an official React Native SDK, which offers a more integrated and often higher-performance experience compared to SQLite wrappers. It leverages Realm’s core capabilities for concurrency and performance.

Test Scenario: Concurrent Writes and Reads

Again, we’ll run the same benchmark: 10 concurrent writes and 5 concurrent reads. Realm’s React Native SDK is designed to handle this efficiently.

Realm Implementation (React Native)

The Realm React Native SDK allows you to open a Realm instance and perform operations. Writes are typically done within writeAsync or writeSync blocks. Reads can be performed on a Realm instance obtained from the main thread or a background thread.

import Realm from 'realm';

// Define Realm object schema
export const ItemSchema = {
    name: 'Item',
    properties: {
        id: 'int', // Primary key
        value: 'string',
    },
    primaryKey: 'id',
};

let realmInstance = null;
let nextId = 0; // For simple ID generation

const initializeRealm = async () => {
    if (realmInstance) return realmInstance;
    try {
        const config = {
            schema: [ItemSchema],
            schemaVersion: 1,
            // deleteRealmIfMigrationNeeded: true, // Use with caution in production
        };
        realmInstance = await Realm.open(config);
        console.log('Realm opened successfully');

        // Initialize nextId based on existing data to avoid collisions if schema is not deleted
        const maxIdObject = realmInstance.objectForPrimaryKey('Item', realmInstance.objects('Item').max('id') || 0);
        nextId = maxIdObject ? maxIdObject.id + 1 : 0;

        return realmInstance;
    } catch (error) {
        console.error('Failed to open Realm:', error);
        throw error;
    }
};

const insertItem = async (value) => {
    const startTime = performance.now();
    try {
        const realm = await initializeRealm();
        let result = null;
        await realm.write(() => {
            const newItem = realm.create('Item', {
                id: nextId++,
                value: value,
            });
            result = { id: newItem.id, duration: 0 }; // Duration will be calculated after write block
        });
        const endTime = performance.now();
        const duration = endTime - startTime;
        console.log(`Inserted item. ID: ${result.id}, Duration: ${duration.toFixed(2)}ms`);
        return { ...result, duration };
    } catch (error) {
        const endTime = performance.now();
        const duration = endTime - startTime;
        console.error('Error during Realm write:', error, `Duration: ${duration.toFixed(2)}ms`);
        throw { error, duration };
    }
};

const readItems = async () => {
    const startTime = performance.now();
    try {
        const realm = await initializeRealm();
        const items = realm.objects('Item');
        const count = items.length;
        const endTime = performance.now();
        const duration = endTime - startTime;
        console.log(`Read ${count} items. Duration: ${duration.toFixed(2)}ms`);
        return { count, duration };
    } catch (error) {
        const endTime = performance.now();
        const duration = endTime - startTime;
        console.error('Error during Realm read:', error, `Duration: ${duration.toFixed(2)}ms`);
        throw { error, duration };
    }
};

// Function to simulate concurrent operations
const simulateConcurrentOperations = async (numWrites, numReads) => {
    const writePromises = [];
    for (let i = 0; i < numWrites; i++) {
        writePromises.push(insertItem(`Value ${i + 1}`));
    }

    const readPromises = [];
    for (let i = 0; i < numReads; i++) {
        readPromises.push(readItems());
    }

    try {
        const results = await Promise.all([...writePromises, ...readPromises]);
        console.log(`Simulated ${numWrites} writes and ${numReads} reads. Total operations: ${results.length}`);
        return results;
    } catch (error) {
        console.error('An error occurred during concurrent operations:', error);
        throw error;
    }
};

// Example usage:
// initializeRealm().then(() => {
//     simulateConcurrentOperations(10, 5);
// });

export { initializeRealm, insertItem, readItems, simulateConcurrentOperations };

The Realm React Native SDK’s realm.write() method is asynchronous and handles transactions. Multiple write() calls from different parts of the app (or simulated concurrently) will be serialized by Realm’s core. Reads are generally non-blocking and can occur in parallel with writes.

Performance Metrics

We will collect:

  • Average JavaScript execution time for insert/read operations.
  • Number of Realm-specific errors.

Analysis of Latencies and Thread Contention

The core difference in latency under thread contention stems from how each database solution and its respective platform/SDK handle concurrent access.

Native Android SQLite

Native Android SQLite, when accessed directly, is inherently single-writer. The ExecutorService(Executors.newSingleThreadExecutor()) in our example explicitly enforces this, serializing all operations. Any perceived “concurrency” is actually queuing. Latency will increase linearly with the number of concurrent requests as they wait for the single database thread to process them. Write operations will block reads until the transaction is complete. The primary bottleneck is the single-threaded access to the database file.

Native Android Realm

Realm’s architecture allows multiple threads to read concurrently. Writes are serialized but are typically very fast due to Realm’s efficient transaction management and memory mapping. While contention will still increase latency for writers, readers should experience minimal impact as long as writes are quick. The performance difference compared to SQLite will be noticeable, especially under heavy read loads.

React Native SQLite

React Native SQLite performance is a composite of the JavaScript overhead, the bridge communication, and the native SQLite performance. The JavaScript thread is the bottleneck for initiating operations. While the native SQLite driver will serialize writes, the latency measured in JS will include the time spent waiting for the bridge and the native execution. If the native SQLite driver itself is heavily contended (e.g., due to many concurrent requests being queued), the JS-reported latencies will reflect this.

React Native Realm

The React Native Realm SDK generally offers the best performance for cross-platform local databases. It minimizes bridge overhead and leverages Realm’s optimized native core. Concurrent reads are efficient, and writes, while serialized, are fast. Latencies are expected to be lower than React Native SQLite, and potentially closer to native Realm performance, depending on the complexity of the data models and operations.

Conclusion and Recommendations

For applications requiring robust local data storage with high concurrency and synchronization needs, the choice between native and React Native, and between SQLite and Realm, has significant performance implications.

  • Native Android vs. React Native: Native development offers finer control and potentially lower overhead, especially for complex background tasks. However, React Native with Realm can achieve performance very close to native for many use cases, with the benefit of cross-platform code sharing.
  • SQLite vs. Realm: Realm generally outperforms SQLite under concurrent read/write loads due to its architecture. If your application experiences significant contention, Realm is the preferred choice for better responsiveness and lower latencies. SQLite is simpler and has a smaller footprint but requires more manual management for concurrency.

Recommendation for Senior Tech Leaders:

  • Prioritize Realm for new projects if cross-platform development is a goal and local database performance under load is critical. The development effort for React Native + Realm is often less than maintaining separate native codebases.
  • For existing native Android applications heavily reliant on SQLite and facing performance issues under load, consider migrating critical data paths to Realm or optimizing SQLite access patterns (e.g., using a single database connection pool managed by a dedicated service).
  • Thorough benchmarking on target devices is essential. The synthetic benchmarks presented here provide a baseline, but real-world usage patterns and device capabilities can significantly influence actual performance. Use tools like Android Studio Profiler and Flipper to identify bottlenecks in your specific application.

Recent Posts

Top Categories

Our Products

Our Services