SQLite in a React Native app is one file on the phone, and the phone is already backing it up.

Where does the file live, and can you look inside it?

Expo publishes a constant called SQLite.defaultDatabaseDirectory and describes it in one line: "The default directory for SQLite databases." It prints no path, for any platform. Read the reference looking for one and you will not find it, which is worth saying plainly instead of repeating a path you saw somewhere else. The functions that take a location, openDatabaseAsync and deleteDatabaseAsync, both default to that same directory.

One sentence gives the Apple answer away, and it does it by describing an exception. Expo's note reads: "On Apple TV, the underlying database file is in the caches directory and not the application documents directory, per Apple platform guidelines." tvOS is the odd one out. Everywhere else on Apple hardware the file is in the application documents directory, which is the directory the system treats as user data worth keeping. On Android, Expo gives no equivalent hint, and the two plausible directories behave the same way for the purposes of the next section, so the gap matters less than it looks.

If you want the real path rather than an inference, the open database object has a read only databasePath property. Log it once on a device in development and you have the answer for that platform. Expo does not document its format, so printing it beats assuming it.

You can also simply look at the data, which is the first thing to do with a project you did not write. Expo says expo-sqlite includes a built-in DevTools inspector plugin that is "automatically enabled in development and requires no extra setup". Press Shift and M in the Expo CLI terminal to open the dev tools menu, then choose Open expo-sqlite. It browses tables, views and edits rows, runs SQL queries and exports databases from your browser. Fifteen minutes in there tells you more about what your app stores than any amount of reading the code.

Two settings move the file somewhere else, and both are deliberate. openDatabaseAsync takes a directory parameter, which Expo says is not supported on web. And on iOS you can put the database in an App Group shared container, using Paths.appleSharedContainers from expo-file-system, so a widget or a share extension can read the same rows. If nobody set either of those, the default directory is where your database is.

Expo, expo-sqlite reference, read 17 October 2026

Is the database backed up, and who decided that?

Expo does not answer this, and the careful version of that sentence matters. On 17 October 2026 we read the expo-sqlite reference and the expo-file-system reference end to end. Neither page mentions iCloud, device backup, or excluding a file from a backup. The word backup appears twice on the SQLite page, both times for backupDatabaseAsync and backupDatabaseSync, which copy one open SQLite database into another. That is a SQLite operation. It has nothing to do with the user's phone backup, and reading the method name as reassurance is the mistake this section exists to stop.

So the operating system decides, and both have already decided. Apple's page Optimizing Your App's Data for iCloud Backup opens with it: when iCloud Backup is in an enabled state, it periodically creates a backup of the user's device, "including your app's data". Apple then names exactly two directories the backup skips, /tmp and /Library/Caches, because the system purges them anyway, and warns that for anything else "iCloud Backup may include that data". By that list, a database in the application documents directory is in the backup. Apple does not name expo-sqlite, or any directory by the name Expo uses, so the chain runs through Expo's own note about Apple TV above. Say so when you repeat it.

Apple does offer a way out, and is unusually blunt about how strong it is. You can set a file or directory's isExcludedFromBackup resource value. Apple then says that value "exists only to provide guidance to the system about which files and directories it can exclude; it's not a mechanism to guarantee those items never appear in a backup or on a restored device". Apple also warns that some file operations reset resource values, so you have to set it again every time you save the file. Read both sentences twice before you promise anyone that something stays on one device.

Android backs it up too, and puts a number on it. Auto Backup applies to apps that target and run on Android 6.0, API level 23, or higher. Its default set includes "Files in the directory returned by getDatabasePath(String), which also includes files created with the SQLiteOpenHelper class", plus files in internal storage, and it excludes the cache, code cache and no-backup directories. The manifest attribute android:allowBackup defaults to true. The data goes to "a private folder in the user's Google Drive account", end to end encrypted on Android 9 and higher using the device PIN, pattern or password. A run happens when the user has backup on, at least 24 hours have passed since the last one, the device is idle and it is on Wi-Fi, and Google says that in practice those conditions "occur roughly every night".

The number is 25 MB. Google writes that "Every app can allocate up to 25 MB of backup data per app user", and that past it "the system calls onQuotaExceeded() and doesn't back up data to the cloud". A local database that grows with use will cross that line quietly. Nobody gets an alert, no build fails, and the user finds out on a new phone. If your app stores photos, attachments or a long history in SQLite, that figure is the most useful thing on this page.

If you decide the database should not travel, each platform has its own switch and they are not the same shape. On Android 12 and higher, for an app targeting API level 31 or higher, you point android:dataExtractionRules at an XML file with cloud-backup, device-transfer and cross-platform-transfer sections. Below that it is android:fullBackupContent with include and exclude elements, where the valid domains include database, file and sharedpref, exclude takes precedence over include, and Google warns that once you specify an include "the system no longer includes any files by default". On iOS it is the resource value above, with Apple's own caveat attached to it.

Android Developers, back up user data with Auto Backup, read 17 October 2026

What breaks when you change a table?

The new install is the easy case. Your setup code runs CREATE TABLE, the tables match the queries, the app works. The existing install is the one that bites. That phone already has the tables you shipped last time, with somebody's real rows in them, and your new query asks for a column that is not there. On a server you would run a migration and watch it. Here it runs on a stranger's phone, once, and you never see it.

Expo documents a pattern rather than shipping a framework. SQLiteProvider takes an onInit prop, described as "A custom initialization handler to run before rendering the children" that you can use "to run database migrations or other setup tasks". The example in the reference reads PRAGMA user_version, compares it against a DATABASE_VERSION constant in your own code, runs the statements for each step it is behind, then writes the new number back with PRAGMA user_version. It is a version counter and a staircase of if blocks. That is all SQLite gives you, and it is enough, as long as nobody ever edits a step that already shipped.

There is no migration tooling inside the library. Expo says expo-sqlite "is designed to be a solid SQLite foundation" and points at third-party integrations instead, naming Drizzle ORM, which it says "has a CLI companion called drizzle-kit for generating SQL migrations", and Knex.js. If your project already has Drizzle in it, somebody made that choice on your behalf and the migration files are sitting in the repo waiting to be read.

Two details about timing are worth holding on to. onInit runs before the children render, so your migration is on the cold start path and a slow one is a slow launch, out of the same budget as everything else in app startup time. And the onError prop defaults to rethrowing the error. A migration that throws, throws at launch, on every existing install at once, and you cannot reach that file to fix it. Ship a schema change the way you would ship a database change to a server you have no login for.

Do you need a server, and when does one phone stop being enough?

No server, and for a lot of apps that is the honest answer rather than a stage you grow out of. A local database has no hosting line, no scaling plan and no invoice that grows with signups, which is a large slice of what an app costs to maintain when the app is mostly one person's own data. The recurring bill you cannot avoid is the store side, and that is the same whether your data is local or not, which is the subject of what it costs to publish an app.

One phone stops being enough at predictable moments. The first is a second device for the same person, because nothing syncs. The second is any feature where someone else has to see the data. The third is a lost phone, and this is the one people misread: the OS backup is the user's safety net, not yours. You cannot read it, you cannot restore one record from it, and you cannot prove it ran. If losing the data would be a support problem for you rather than a shame for them, you need your own copy.

Two more facts catch people out. The database is not encrypted by default. Expo supports SQLCipher, "a fork of SQLite that adds encryption and authentication to the database", on Android, iOS and macOS, through a useSQLCipher config plugin property followed by npx expo prebuild, with the password set using PRAGMA key right after you open the database. Expo notes SQLCipher is not supported in Expo Go, so it needs a new build rather than a reload. Decide it before you have users, because turning it on later means moving existing rows out of a plain file.

If the project also targets web, that is a different engine under the same API. Expo says that on web expo-sqlite "uses a prebuilt WebAssembly build of SQLite without full-text search (FTS)". The directory parameter is not supported there, nor is withExclusiveTransactionAsync, and a deployed web build needs Cross-Origin-Embedder-Policy and Cross-Origin-Opener-Policy headers before the thing will load at all. A feature that works on the phone can be missing on the web build for reasons that have nothing to do with your code.

You may also have a SQLite database you never asked for. expo-sqlite ships a key-value Storage API as a drop-in replacement for AsyncStorage, backed by SQLite, so an app that only saves preferences may still be keeping them in a SQLite file under every rule above. And one line on security is worth repeating in full, because it is the only vulnerability class this library can hand you: Expo says you "must escape all user input passed to SQLite", and that prepared statements are the defence, because they separate the query from its parameters.