Nitro SQLite: a synchronous SQLite binding for React Native built on Nitro Modules

A native module, which is the constraint and the point

Nitro SQLite is a SQLite library for React Native on iOS, macOS, visionOS and Android, built with Nitro Modules, and it provides synchronous and asynchronous queries, transactions and batch operations. The primary language in the repository listing is C, with C++ and native topics, which is the expected shape for a library that compiles a real SQLite build into the app rather than bridging to something already on the device. The topic list names android, ios, nitro, nitro-modules, nitrogen, react-native, sql, sqlite and storage, so the boundary is clear: this is a database binding, not an ORM, and there is no query builder or migration framework in the readme. The Nitro Modules dependency is what makes the synchronous API possible, since a JavaScript call that returns a value has to cross the bridge synchronously, and that is a harder problem than the usual asynchronous one.

Installation is one command, then a native rebuild

The requirements are React Native 0.75 or newer and react-native-nitro-modules 0.37.1 or newer, and the install itself is a single command.

npm install react-native-nitro-sqlite react-native-nitro-modules

Then you rebuild the native app after installing, which is the step that catches people out, because a JavaScript-only change to a native module does nothing until the native side is recompiled. The Expo case is called out specifically: Expo projects need a development build, and Expo Go cannot load this native module. That is a real constraint for anyone prototyping in Expo Go, and it means the move to this library also means moving to a development build or a bare workflow. The documentation site at sqlite.margelo.com carries the full setup, guides, integrations and API reference.

The example shows a synchronous open, execute and read

The readme example is short enough to read in full, and the shape of it is the API shape. You import the open function, open a database by file name, execute a create table statement, insert a row with a bound parameter, then read it back with a typed execute call and close the connection.

import { open } from 'react-native-nitro-sqlite'

const db = open({ name: 'app.sqlite' })
db.execute('CREATE TABLE IF NOT EXISTS notes (id INTEGER PRIMARY KEY, body TEXT)')
db.execute('INSERT INTO notes (body) VALUES (?)', ['Hello'])

const { rows } = db.execute<{ id: number; body: string }>(
  'SELECT id, body FROM notes',
)
console.log(rows._array)

db.close()

Two details stand out. The insert uses a bound parameter rather than string interpolation, which is the right way to write it. And the execute call is generic, so the row type is given at the call site as a TypeScript type parameter, with the result coming back as an object whose rows carry an _array property. The synchronous shape is the headline: the read happens in the same tick as the call, with no await.

R*Tree is compiled in by default, and you can turn it off

The bundled SQLite build enables R*Tree indexes by default on Apple platforms and Android, and the readme links to its own documentation on spatial range queries. That is a meaningful default for a mobile database, because R*Tree is what makes bounding box and polygon queries on geometry columns possible at all, and building it in means you do not have to rebuild SQLite yourself to use spatial features. If you do not want it, you set nitroSQLite.enableRTree to false in your app's package.json, and it is omitted from the native build. The feature is exposed as a build-time flag in the package manifest rather than as a runtime option, which makes sense given that the index support has to be compiled into the SQLite library itself. The cost of the default is binary size, and the cost of turning it off is losing spatial queries, so the decision is a straightforward size against capability trade.

A migration path from react-native-quick-sqlite, and existing files

The readme is explicit about the predecessor, because this library replaces a well known one. react-native-quick-sqlite 8.x was succeeded by react-native-nitro-sqlite 9.x, and the readme tells you to follow the migration guide before updating an app that has existing database files. That caveat is the important part. Migrating a library is one thing, and migrating a library that has already written data to a device is another, since the file format, the schema and any table that depended on a feature you are dropping all sit in that file. The current line is at 10.2.0, with 10.1.0 and 10.0.1 released on 2026-10-01 and 10.2.0 on 2026-10-12, and the repository is not archived with the last push on 2026-10-19, so this is a project on an active release line. The version numbers to watch are the Nitro Modules floor at 0.37.1 and the React Native floor at 0.75.

A monorepo with a Bun workspace and an example app for every platform

The repository is a Bun workspace, with the root package.json naming the workspace react-native-nitro-sqlite-workspace at version 10.2.0 and listing packages, example, example/macos and docs as workspaces. The package manager field pins bun at 1.3.1, and the scripts show the division of labour, with sqlite, example and docs each run through bun with a working directory, plus a lint:cpp script that runs a clang-format shell script, which is consistent with a native C++ codebase sharing one root with its TypeScript packages. The engines field requires Node 22.13.0 or newer even though the project itself is driven by Bun, which suggests Node is still needed for the React Native tooling. The example directory is unusually complete, with its own android, ios, macos and src folders, a Gemfile, babel and metro configs, a jest config and a separate jest mocha config, and both an rn-harness.config.mjs and a react-native.config.js. There is a patches directory with a postinstall script running patch-package, so the project ships patches to its dependencies, which is a detail worth knowing if you hit a dependency problem.

Editorial conclusion

react-native-nitro-sqlite fits a React Native application that needs a genuine on-device database with spatial queries, where the synchronous API is a feature because it removes the promise round trip from every read, and where a native rebuild is acceptable in the pipeline. It does not fit a project still on Expo Go or on React Native below 0.75, and it does not fit an app that cannot accept a native dependency in its build. Before you adopt it, confirm your app already ships a development build rather than relying on Expo Go, decide whether the bundled R*Tree support is worth keeping in the native build for your app's size, and if you are coming from react-native-quick-sqlite, read the migration guide first, since that project was succeeded by the 9.x line and existing database files need attention.

Frequently asked questions

Official sources

1. License: MIT
2. margelo/react-native-nitro-sqlite on GitHub
3. Project website
4. README
5. Releases