Cloud Parts

SQLite

A complete SQL database in a library and a single file, with no server to run.

Type
Open source
Made by
The SQLite developers (Hwaci)
License
Public domain
Facts checked
5 October 2026

What it is

SQLite is not a server. It is a library, under 900 KiB with every feature, that your program links in and calls directly. The whole database (tables, indexes, triggers, views) lives in one ordinary file that you can copy, email or check into a test fixture. Opening the database is opening the file, so there is no network hop, no user accounts and nothing to configure. Its authors describe it as a replacement for fopen(), not for Oracle.

It still gives you real SQL and ACID transactions that survive power loss. In write-ahead-log (WAL) mode, readers and a writer work at the same time, but only one writer can commit at a time per file. A database can reach 281 TB, the file format works across platforms, and the developers promise to support it through 2050. It is the most widely deployed database in the world, inside phones, browsers, cars and desktop apps, and it serves many small to medium websites.

Why teams pick it

  • Zero administration: no server, no ports, no accounts
  • Queries run in-process, so there’s no network round trip
  • One portable file is easy to back up, ship and test against
  • Public domain, heavily tested, with a stable file format

Watch out for

  • One writer at a time per database file, so write-heavy multi-user apps outgrow it
  • All processes must be on one machine; WAL mode doesn’t work over a network file system
  • No built-in replication, user accounts or network access; separate tools have to add them, and forks such as libSQL and Turso add replicas, sync and concurrent writers
  • Types are flexible by default, so a column accepts values of other types unless you use STRICT tables

Alternatives

What all relational databases have in common →
Alibaba Cloud PolarDBCommercialAlibaba Cloud’s cloud-native relational databases: MySQL- and PostgreSQL-compatible clusters whose compute nodes share one copy of the data on distributed storage, plus PolarDB-X, a distributed MySQL-compatible edition.CedarDBCommercialA PostgreSQL-compatible database rebuilt from scratch at TU Munich, running transactions and analytics on one copy of the data on a single server.Cloudflare D1CommercialCloudflare’s serverless SQL database that speaks SQLite, runs each database inside a Durable Object, and bills by rows read and written rather than by the hour.CloudNativePGOpen sourceA Kubernetes operator that runs highly available PostgreSQL with no Patroni and no StatefulSets: the Kubernetes API itself holds the cluster’s state.CockroachDBCommercialA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.MySQLOpen sourceThe long-standing open-source SQL database behind much of the web, built on the InnoDB engine.NeonCommercialServerless Postgres that keeps data in a shared storage layer, so compute can scale to zero and a branch of the database is a pointer, not a copy.PatroniOpen sourceA Python agent beside each Postgres server that elects one primary through etcd, Consul, ZooKeeper or Kubernetes, and fails over when it dies.Percona OperatorsOpen sourceFour free Kubernetes operators from Percona that run its builds of MySQL, PostgreSQL and MongoDB, each using the engine’s own replication and backup tools.PGO (Crunchy Postgres for Kubernetes)Open sourceCrunchy Data’s Postgres operator: Patroni in every pod for failover, pgBackRest for backups, and a declarative `PostgresCluster` resource on top.PlanetScaleCommercialManaged MySQL on Vitess and managed Postgres, with schema changes shipped through branches and deploy requests.PostgreSQLOpen sourceThe open-source relational database that most new projects start on, extensible enough to grow into many niches.ScramDBCommercialA brand-new, closed-source database that speaks the PostgreSQL protocol and promises transactions, analytics and vector search on one copy of the data; first builds shipped in summer 2026.TursoOpen sourceA from-scratch Rust rewrite of SQLite with concurrent writes, plus libSQL (an open-contribution SQLite fork) and Turso Cloud, which hosts many small databases on S3.VitessOpen sourceA proxy layer, born at YouTube, that shards MySQL across many servers while the app still sees one database.

How it fits with other technologies

What uses SQLite

An embedded database with Python’s standard library · python

import sqlite3

con = sqlite3.connect("app.db")              # creates the file if needed
con.execute("PRAGMA journal_mode=WAL")       # readers don't block the writer
con.execute("CREATE TABLE IF NOT EXISTS notes (id INTEGER PRIMARY KEY, body TEXT NOT NULL)")

with con:                                    # one transaction, committed on exit
    con.execute("INSERT INTO notes (body) VALUES (?)", ("buy coffee",))

for note_id, body in con.execute("SELECT id, body FROM notes ORDER BY id"):
    print(note_id, body)

See it in a real stack

No architecture uses SQLite yet. Drop it into the playground and wire it up yourself.Open playground →

Benchmarks

How to read a benchmark →
Where it came from2000–2025

In 2000, D. Richard Hipp was leading a team writing damage-control software for a US Navy guided-missile destroyer, as a contractor. The software used an Informix database server, and when that server went down the application wouldn’t run; a dialog box popped up saying “Can’t connect to database server.” On a warship that has taken battle damage, that is the last thing the crew should see. Hipp asked why the program needed a server at all, instead of reading its data straight off the disk, and found no SQL engine that worked that way.

When a budget fight paused government contracts that year, he had a few months free and wrote one. SQLite began as a Tcl extension; version 1.0 came out in August 2000, storing data with gdbm. Version 2.0 in September 2001 replaced gdbm with Hipp’s own B-tree, and version 3.0 followed in June 2004, made possible in part by developers at AOL.

Phone makers came next: Motorola, then Symbian, which chose SQLite after a bake-off against nine other engines, then the team building Android. Shipping on millions of devices exposed bugs, so Hipp adopted the aviation software standard DO-178B and spent a year of 60-hour weeks writing tests until every branch was covered. Today SQLite is likely used more than all other database engines combined.

Why it’s built this way

A library inside the program, not a server
The Informix outages showed that a separate server is one more thing that can fail. SQLite was designed to run without installing a database system or needing an administrator.
Compile SQL into bytecode for a small virtual machine
Hipp had built compilers before, so he treated each SQL statement as a program: a compiler translates it into bytecode, and a small engine runs that bytecode.
Flexible column types
SQLite started as a Tcl extension, and Tcl is dynamically typed, so a column accepts values of other types. STRICT tables, which reject mismatches, arrived only in 2021.
Public domain, every line written from scratch
With no licence terms at all, anyone can ship SQLite in anything. To keep it that way, every contributor signs a public-domain dedication, and patches from anyone else aren’t accepted.

Timeline

  1. 2000

    Hipp writes SQLite; version 1.0 is released in August

  2. 2001

    Version 2.0 replaces gdbm with its own B-tree

  3. 2004

    Version 3.0 arrives in June, supported in part by AOL

  4. 2010

    3.7.0 adds write-ahead logging (WAL)

  5. 2021

    STRICT tables offer enforced column types

  6. 2025

    SQLite turns 25 with version 3.50.0 in May

Sources12 · facts checked 5 October 2026

Improve this page on GitHub