document database
Document database: between SQLite and NoSQL
Databases are the invisible backbone of modern software. They store data in a structured way, so that programs can work with it quickly and reliably. Within the world of databases, there are different categories, each with its own purpose, architecture and use cases. Two approaches that are often contrasted with each other are relational databases — represented by SQLite — and NoSQL databases. Although SQLite is technically not a document database, it is sometimes mentioned in the same breath as NoSQL solutions because of its lightweight, file-based structure and simple integration into applications. To understand what a document database is and how SQLite relates to the NoSQL landscape, it must first be made clear what these terms mean and where they come from.
SQLite is a relational database engine that was developed in 2000 by D. Richard Hipp. The project started on May 9, 2000, and the first stable version, 1.0, appeared on August 17, 2000. Hipp developed SQLite in the spring of 2000 while working for General Dynamics under contract to the United States Navy. The goal was to create a lightweight, serverless database that was easy to integrate into embedded systems. Unlike traditional relational databases such as PostgreSQL or MySQL, SQLite does not require separate server processes. The entire database is stored in one file on disk, which makes it ideal for mobile apps, desktop software and small applications where scalability and concurrency are not a priority.
The strength of SQLite lies in its simplicity and reliability. It supports SQL, the standard language for querying and manipulating relational data. Users can create tables, insert, query and update data via the `sqlite3` command-line tool or via APIs in programming languages such as Python, JavaScript or C. It is fully ACID-compliant (Atomicity, Consistency, Isolation, Durability), which means that transactions are reliable, even during power outages or crashes. SQLite can be found everywhere: in smartphones, browsers, IoT devices and even in aerospace software. It is one of the most distributed software components in the world.
Yet SQLite is not a document database. Document databases fall under the broader category of NoSQL databases. The term NoSQL is confusing, because it literally means “non-SQL,” but in practice it refers to databases that deviate from the classic relational model. Instead of fixed tables with rows and columns, document databases store data in flexible formats such as JSON, BSON or XML. Each “document” can have its own structure, which offers a lot of freedom when storing semi-structured or unstructured data. Think of user profiles with changing fields, log files, product information in e-commerce, or sensor data from smart devices.
The term NoSQL was first used in 1998 by Carlo Strozzi, for a relational database without an SQL interface. Ironically, his system was therefore still relational, but without the usual query language. The term only received attention again in 2009, when Eric Evans and Johan Oskarsson used it in the context of newly emerging, scalable, non-relational databases. This was a response to the growing need of companies such as Google, Amazon and Facebook to process enormous amounts of data quickly, often without the limitations of fixed schemas. According to a source from OVHcloud Netherlands, NoSQL arose as an answer to the need to process unstructured data more efficiently than was possible with traditional relational databases.
Document databases such as MongoDB, CouchDB or Firebase are typical examples of this. They use a key-value or document model in which each document has a unique key and a JSON-like structure. This flexibility makes development faster, especially in agile environments where the data model often changes. No schema upgrade is needed when adding new fields — something that does have to be arranged in SQLite or other relational systems via `ALTER TABLE` or migrations.
Yet there are similarities between SQLite and document databases. Both are often serverless and embedded. Both are lightweight and suitable for offline or edge use. And both are widely used in mobile and desktop applications. Some developers use SQLite as a kind of “poor man’s document store” by storing JSON blobs in text fields. Although this works, it is not a real replacement for a real document database, because then you miss the benefits of schema validation, indexed field access and optimized queries.
An interesting fact is that SQLite continues to evolve. According to the official chronology, releases are planned far into the future, including version 3.53.2 on June 3, 2026 and version 3.53.4 on July 24, 2026. This shows that work is still actively being done on it, despite the rise of NoSQL and cloud databases. The developers continue to improve the engine in areas such as performance, security and SQL support.
SQLAlchemy, a popular ORM (Object-Relational Mapper) for Python, also continues to support SQLite in its latest versions. The documentation of SQLAlchemy 2.0, published on August 11, 2026, contains specific sections on engine configuration for SQLite, which indicates that it is still a relevant player in modern development. SQLAlchemy makes it easier to work with SQLite by translating object-oriented code into SQL, but it remains based on the relational model.
In summary: a document database is a type of NoSQL database that stores data in flexible documents, usually in JSON-like formats. It differs fundamentally from SQLite, which is a relational, SQL-based, schema-driven database. Yet they share certain characteristics: simplicity, embedded use, and suitability for small to medium-sized applications. The choice between SQLite and a document database depends on the use case. If you need to manage data with a fixed schema and use SQL queries, then SQLite is an excellent choice. If you work with variable, nested or unstructured data and want to scale to large volumes, then a document database is often more suitable.
The history of both technologies shows that there is no “one greatest” database. SQLite arose from a military need for reliable, light storage. NoSQL arose from the pressure of internet companies to scale quickly. Both have found their niche. While NoSQL is popular in cloud-native and real-time applications, SQLite remains irreplaceable in systems where simplicity, reliability and offline operation are important.
There is no indication that SQLite will disappear. On the contrary: the planning of releases until 2026 and the continued support in frameworks such as SQLAlchemy show that it is a living project. It may not evolve in the direction of a document database, but it remains a crucial part of the software infrastructure. For developers, this means that they can choose from a wide range of tools, depending on their needs — from the strict model of SQLite to the free form of NoSQL document databases.