.db vs .sqlite vs .sqlite3: what's the difference?

Short answer: there’s no difference in the file itself. A SQLite database is the same format whether it’s called data.db, data.sqlite, data.sqlite3 or just data. SQLite never looks at the extension; it reads the file’s header. The extension is a convention chosen by whoever created the file.

The common extensions

Extension	Where you’ll see it	Notes
.db	Android apps, iOS apps, many desktop apps	Short and generic. Other databases use .db too, so it’s the least specific.
.sqlite	Firefox profiles (places.sqlite, cookies.sqlite), many Mac and iOS apps	Clearly says SQLite.
.sqlite3	Django projects (db.sqlite3), Python and Ruby tooling	Says SQLite version 3, the current format.
.db3, .s3db, .sl3	Older Windows tools and some libraries	Rare variants of the same thing.
(no extension)	Chrome and Edge profile files such as History and Cookies	Still SQLite inside.

All of these open in any SQLite tool. In OpenSQLite, the file picker shows .db, .sqlite and .sqlite3 files; for any other name, drag the file onto the drop zone and it opens as long as it’s a valid SQLite database.

Why “3”? SQLite 2 vs SQLite 3

SQLite 3 was released in 2004 with a new file format that isn’t compatible with SQLite 2. Every SQLite file you’re likely to meet today is version 3, and that format has stayed backwards compatible ever since: a file written by SQLite 3.0 still opens in today’s SQLite.

The .sqlite3 extension was a way to make the version explicit while both formats were around. If you ever find a genuinely old SQLite 2 file, modern tools (including OpenSQLite) can’t open it. SQLite 3 files start with the text SQLite format 3; SQLite 2 files start with a different line.

Which extension should you use?

For your own projects, any of them is fine. Some practical tips:

• .sqlite3 or .sqlite make it obvious what the file is, to people and to tools that pick an app by extension.
• .db is short and widely recognised, but also used by unrelated formats, so it says less.
• Pick one and stay consistent across a project, especially in .gitignore rules and backup scripts.

Renaming a database file is safe, as long as no program has it open while you rename it. Rename its companion files (below) at the same time.

The files next to your database: -wal, -shm and -journal

You may see extra files with the same name plus a suffix. They belong to the database and matter when you copy or move it.

File	What it is	Do you need it?
name.db-wal	Write-ahead log. In WAL mode, SQLite writes new changes here first and merges them into the main file later.	Yes, if it isn’t empty. Without it, the most recent changes are missing.
name.db-shm	Shared-memory index for the WAL file, used to coordinate programs reading the database at the same time.	No. SQLite rebuilds it, but copying it does no harm.
name.db-journal	Rollback journal, used in the default (non-WAL) mode while a change is being written.	Keep it with the database. If a write was interrupted (a crash or power cut), SQLite uses it to restore the database to a consistent state.

The safest way to copy a SQLite database is to close the program using it first. It then normally merges the WAL into the main file and removes the journal, leaving a single file. If you can’t close it, copy the .db and its -wal file together.

OpenSQLite opens one file at a time. If a database was in WAL mode, it opens the main file and shows a note that recent changes may be missing, so you know to close the app or merge the WAL first if you need the latest data.

How to tell what a file really is

Because the extension is only a hint, the reliable check is the header. Open the file in a text editor: a SQLite 3 database begins with SQLite format 3. Or open it in your browser, which checks the header and tells you if the file isn’t SQLite. The guide to opening .db files covers the other kinds of .db file you might have.