Summary

  • SQLite's release log places four decisions in its 20 September 2001 entry for version 2.0-alpha-2: keep the SQLite name instead of SQLus; restore the pager and B-tree as the only backend; remove the Dbbe abstraction and GDBM and memory drivers; disclaim copyright on all code.
  • SQLite's own version history identifies GDBM as the storage engine through 1.0.32 and a custom B-tree engine for the 2.x line. Its historical leading version number tracked the database file format, so the change was deeper than a new marketing label.

Two doors, one release

The most quotable line in a software licence history is often a statement of permission. SQLite's September 2001 entry has one: copyright on all code was disclaimed and the library entered the public domain. The same entry says something less romantic about the product that people could actually run. Its pager and B-tree subsystems came back as the only available backend. The Dbbe abstraction disappeared with the GDBM and memory drivers. A developer could take the code without negotiating a licence; a developer using SQLite 2 had one supported storage path supplied by the project.

Those are separate choices. The current SQLite copyright explanation says users may copy, change, publish, compile, sell or distribute the deliverable library. It describes rights over the code. It does not promise a menu of storage engines, and the release note makes no claim that the public-domain decision caused the backend decision. They shared a date and a release. That is enough to make the contrast historically interesting without inventing a motive.

The GDBM years had already shown the cost of a storage layer

SQLite's version-number account gives a clean architectural dividing line: versions 1.0 through 1.0.32 used GDBM, while 2.0.0 through 2.8.17 used a custom B-tree engine for text keys and data. The old leading version number indicated file format, not simply the age of a product. A 2.0 release therefore announced a change in what a database file meant to the library.

The 4 April 2001 entry shows why a storage backend is not a cosmetic plug-in. Version 1.0.28 added limited transactions. On GDBM, these performed table locking; rollback and atomic commit were not yet supported. A public SQL command could appear in the interface while its safety properties depended on the machinery underneath. That is the difference between a feature name and an operational guarantee. The project added a pager on 15 April but said explicitly that it was not yet in use.

Then the engineering plan lurched. On 23 July, release 1.0.32 removed the pager and B-tree subsystems. The stated plan was to use them in a follow-on SQL server library called SQLus. Two months later, the 20 September alpha-2 entry abandoned that name, kept SQLite, restored the two subsystems and dropped the old driver structure. The release log does not explain every internal debate. It does preserve the reversal: a component once earmarked for a separate product became the storage core of SQLite itself.

A public-domain library still had an owner of design decisions

The change did not end at alpha-2. The 27 September alpha-3 entry records fixes to rollback and locking behavior and a file-format change back to alpha-1's layout. The 28 September 2.0.0 entry records automatic Linux and Windows binary builds posted to the website. The sequence matters. “2.0” on 20 September was the project's initial alpha release; the numbered 2.0.0 arrived eight days later. The test of an architecture was in file formats, locking and binaries that people could install, not in the declaration alone.

Public-domain permission gives downstream users extraordinary latitude. A downstream team can fork the code and build a different backend at its own expense. That is different from SQLite maintaining several interchangeable backends in its own releases. The project concentrated its supported implementation while removing a legal barrier to reuse. Some users gained freedom to copy; none gained a contractual right to dictate the project's storage design.

The later SQLite 3 B-tree and file format have their own history. Reading their binary and Unicode capabilities back into 2001 would blur the real stakes. The 2.x design described by SQLite's version history was a custom B-tree engine limited to text keys and data. It replaced GDBM inside the library's shipped path. That is the technical fact a user of the 2001 release would have had to confront.

SQLite's decision exposes a durable split in software history. Permission can be broad while the official executable path is narrow. The public may hold the source, but the maintainer still decides which implementation gets built, fixed, documented and distributed. In September 2001, both doors moved. Only one of them was a licence door.