SQLite

SQLite — Embedded SQL engine that runs inside your process — a file, not a server. SQLite is a C library that implements a small, fast, transactional SQL engine reading and writing a single cross-platform file. There is no daemon, no configuration and no network protocol; a query is a function call. It is developed by a three-person team at Hwaci, funded by a consortium of members, and released into the public domain with a test suite far larger than the engine itself. Founded 2000. Open source under Public domain.

We track it in 1 comparison — Database engines — so every claim below is a cell in a table you can open and check rather than an impression. Across those rosters it sits against 4 other tools, and what follows is where it visibly separates from them.

Where it wins.

• Ops burden — 1, tied for best across 2 of 5 tools.

Each of those is ranked against the whole roster on its category page, not against a hand-picked subset, so a first place here means first of everything we list.

Where it gives ground.

• Online schema change — No. MySQL records Yes.
• ALTER TABLE — Severe (rebuild required), the weakest of the 5 here. PostgreSQL records Minimal.
• Replication — Third-party only, 4th of 5. PostgreSQL records Built-in async + synchronous.
• Migration tooling — 3, 3rd of 5. PostgreSQL records 5.

None of these disqualify it on their own. They are the fields to check against your own requirements before you commit, because they are the ones where a competitor genuinely does better.

Provenance. 25 of 26 tracked fields carry a value for SQLite, and 20 of those cite a document you can open. Last verified 2026-07-01. Every figure keeps its own provenance — measured by us, claimed by the vendor, inferred, or community-reported — and we would rather print a dash than a guess.

Its nearest neighbour in our data is DuckDB. SQLite is ahead on Client libraries (5 against 3) and PITR (Partial against No). DuckDB takes Type strictness (Static, strict against Dynamic (per-value)) and GitHub stars (33,000 against 8,000). That pattern repeats across the rest of the roster — see SQLite alternatives for the other rivals, each compared the same way.

Founded

2000

Licence

Public domain (open source)

Fields we track

25 of 26

Last verified

2026-07-01

The best answer for any workload where one process owns the data, and the answer most teams reject for reasons that stopped being true a decade ago. The real constraints are the single writer, the absent replication story and the table rebuild you need for most schema changes — none of which is throughput.

Ops burden

11st of 5

Inferredverified 2026-07-01

Online schema change

○No4th of 5

Vendor-claimedverified 2026-07-01source

ALTER TABLE

Severe (rebuild required)5th of 5

Vendor-claimedverified 2026-07-01source

Replication

Third-party only4th of 5

Vendor-claimedverified 2026-07-01source

Migration tooling

33rd of 5

Inferredverified 2026-07-01

Extension ecosystem

42nd of 5

Inferredverified 2026-07-01

Client libraries

51st of 5

Inferredverified 2026-07-01

Embed in closed source

●Yes1st of 5

Vendor-claimedverified 2026-07-01source

SQLite is the right call in these situations, each one drawn from a field we actually record:

• One application process, or one machine, owning the data.
• Read-heavy workloads where removing the network hop is the whole win.
• Anything shipped to the edge, a device, a CLI or a test suite.
• Ops burden is your binding constraint. SQLite records 1, the best figure in the Database engines roster. We define that field as 1–5, lower is less work.

Reach for something else when any of the following is a requirement rather than a nice-to-have:

• Online schema change. SQLite records No on the Database engines table. MySQL records Yes on the same field. If that is a hard requirement rather than a preference, start elsewhere.
• ALTER TABLE. SQLite records Severe (rebuild required), the weakest of the 5 tools in the Database engines roster. PostgreSQL records Minimal on the same field. If that is a hard requirement rather than a preference, start elsewhere.
• Replication. SQLite records Third-party only, 4th of 5 in the Database engines roster. PostgreSQL records Built-in async + synchronous on the same field. If that is a hard requirement rather than a preference, start elsewhere.
• Migration tooling. SQLite records 3, 3rd of 5 in the Database engines roster. PostgreSQL records 5 on the same field. If that is a hard requirement rather than a preference, start elsewhere.
• JSON support. SQLite records Text functions only, 3rd of 5 in the Database engines roster. PostgreSQL records Binary JSONB + indexes on the same field. If that is a hard requirement rather than a preference, start elsewhere.

We publish this block because a comparison that only lists what a tool is good at is marketing. Every figure above sits on the same page as its source, and the field definitions are on the category tables if you want to check how we measured them.

What we don't know. 1 of the 26 fields we track for SQLite are still blank: Default max conns. Those render as dashes rather than as zeroes or assumptions, because an empty cell and a bad cell are not the same thing and only one of them is honest. If you know any of these figures and can point at a document, tell us.