MongoDB and SQLite: two databases, two architectures

The database was launched in 2009 by the company 10gen, founded in 2007 by Dwight Merriman, Eliot Horowitz, and Kevin Ryan. The name MongoDB is derived from "humongous" — the database is designed for large amounts of data that do not fit into fixed table structures.

Horizontal scaling with sharding

MongoDB distinguishes itself from relational databases through horizontal scalability. Relational databases often rely on a single powerful server (vertical scalability). MongoDB can be expanded across multiple servers via sharding, where data is automatically distributed across different machines.

Additionally, MongoDB supports replica set architectures. Data is automatically replicated to multiple nodes. This ensures reliability, high availability, and faster read operations, because queries can be distributed across multiple replicas.

Installing and testing MongoDB

The following steps install MongoDB Community Server on a Debian/Ubuntu system and test the basic functionality.

1. Import the MongoDB GPG key and add the repository:

curl -fsSL https://www.mongodb.org/static/pgp/server-7.0.asc | sudo gpg -o /usr/share/keyrings/mongodb-server-7.0.gpg --dearmor
echo "deb [ signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg ] http://repo.mongodb.org/apt/debian bookworm/mongodb-org/7.0 main" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list

2. Update the package list and install MongoDB:

sudo apt-get update
sudo apt-get install -y mongodb-org

3. Start the MongoDB service and check the status:

sudo systemctl start mongod
sudo systemctl status mongod

4. Open the MongoDB shell and create a test database:

mongosh
use testdb
db.users.insertOne({ name: "Pixzo", role: "admin", active: true })

5. Add a document with a different structure — this works without schema changes:

db.users.insertOne({ name: "Tux", role: "user", active: false, lastLogin: new Date() })

6. Retrieve all documents:

db.users.find().pretty()

7. Verify that both documents with different structures are in the same collection:

db.users.countDocuments()

SQLite: embedded relational database

SQLite is an embeddable relational database engine, developed by D. Richard Hipp in 2000 during his work for General Dynamics on contract for the United States Navy. Unlike MongoDB, which runs as a separate server, SQLite is a standalone, serverless library that is built directly into an application. Data is stored in a single file on disk.

SQLite is written in C and available on virtually every platform — from smartphones to routers. It is present in almost every Android and iOS application, web browsers such as Chrome and Firefox, and operating systems such as Windows and macOS.

SQLite encryption with SQLCipher

SQLite does not support native encryption. For encrypted storage, use SQLCipher, a fork of SQLite that adds AES-256 encryption. An example of this approach is AloxBook, a Linux desktop app for financial administration. Without a password, AloxBook uses an unencrypted SQLite database; with a password, it switches to SQLCipher.

The simplicity of SQLite is underscored by tools such as sqldiff, a command-line utility that shows differences between two SQLite databases. It generates an SQL script that transforms one database into the other — useful for version control, migrations, and debugging.

Testing SQLite on Linux

SQLite is standard on most Linux distributions. The following steps test the basic functionality.

1. Check the installed version:

sqlite3 --version

2. Create a database and add a table:

sqlite3 test.db "CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, role TEXT);"

3. Insert data:

sqlite3 test.db "INSERT INTO users (name, role) VALUES ('Pixzo', 'admin');"

4. Retrieve the data:

sqlite3 test.db "SELECT * FROM users;"

5. Show the differences between two databases with sqldiff:

sqlite3 test2.db "CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, role TEXT);"
sqldiff test.db test2.db

Comparison: MongoDB versus SQLite

MongoDB and SQLite differ fundamentally in architecture, usage, and target audience.

| Feature | MongoDB | SQLite | |---------|---------|--------| | Type | NoSQL, document-oriented | Relational | | Architecture | Client-server, distributed | Embedded, serverless | | Storage | BSON documents in collections | Single file on disk | | Schema | Schema-agnostic, flexible | Fixed schema with tables and columns | | Scaling | Horizontal via sharding | Vertical, limited to one machine | | ACID transactions | Limited, growing in modern versions | Full | | Ideal for | Large, dynamic, distributed systems | Small to medium local storage |

MongoDB excels in scenarios where data grows quickly, where schemas change often, and where high availability and scalability are essential — social media, e-commerce platforms, or real-time monitoring. SQLite is perfect for apps that don't need to support complex queries or multiple concurrent users — mobile apps, desktop software, and system tools.

The two databases are complementary, not competitors. MongoDB runs in the cloud or on a cluster; SQLite runs in the background of your phone or laptop.

NoSQL: no standard, but a philosophy

MongoDB is a prominent representative of the NoSQL paradigm, but not the only one. NoSQL is not a technology but an approach. It encompasses document databases (MongoDB), key-value stores (Redis), column-family stores (Cassandra), and graph databases (Neo4j). Common feature: moving away from the strict relational model in exchange for scalability, performance, and flexibility.

The choice for NoSQL is driven by the need for schema-agnostic design. In traditional relational databases, you define in advance which columns a table has, which data types are used, and how tables are connected to each other. With MongoDB, that's not necessary: each document can contain unique fields, and the schema can evolve during runtime. This is useful in agile development where requirements change quickly.

NoSQL also has disadvantages. It often lacks ACID properties (Atomicity, Consistency, Isolation, Durability) in the strict form that relational databases offer. Although modern versions of MongoDB offer increasing transactional support, it remains more difficult to execute complex, consistent transactions across multiple collections. SQLite supports full ACID transactions and is therefore more reliable for local, consistent storage.

Verification

Check that both databases function correctly:

mongosh --eval "db.runCommand({ ping: 1 })"
sqlite3 test.db "PRAGMA integrity_check;"

The MongoDB query returns `{ ok: 1 }`. SQLite returns `ok` if the database is intact.

Common problems

1. MongoDB doesn't start after installation — Check that the database directory path is correct. MongoDB requires that the directory `/var/lib/mongodb` exists and is owned by the `mongodb` user:

sudo mkdir -p /var/lib/mongodb
sudo chown -R mongodb:mongodb /var/lib/mongodb
sudo systemctl restart mongod

2. SQLite database is locked — SQLite doesn't support concurrent writers. Check that no other process has the database open:

lsof /path/to/database.db

3. MongoDB sharding doesn't work with replica sets — Sharding requires that each shard node is part of a replica set. Configure the replica set first with `rs.initiate()` before enabling sharding via `sh.addShard()`.

The database world is not either-or. The choice between MongoDB and SQLite depends on your use case: do you have a distributed system with dynamic data, or a local application with a fixed structure — and the boundary between the two is blurring as tools like SQLCipher and MongoDB Atlas continue to shift the landscape.