Why WeChat Chooses SQLite for 1.3 Billion Users' Chat Records

Introduction: Chat Records Live on Your Phone, Not Tencent's Servers

WeChat's chat records are not stored on Tencent's servers by default. When you switch phones, your chat history is empty until you manually migrate it via the "Chat Record Migration" feature. This design was initially criticized—QQ supports cloud roaming, so why not WeChat? The answer lies in scale: 1.3 billion users, each generating dozens of messages daily (a few hundred bytes each), would produce tens of petabytes of new data per day and exabytes per year. Storing this "cold data" (90% of messages are never revisited after a few days) in the cloud would require massive data-center investment with poor ROI. Instead, WeChat offloads storage to users' devices; servers only relay messages.

An embedded database powers the chat history of 1.3 billion people.

Local Storage Architecture: WCDB on Top of SQLite

WeChat uses WCDB (WeChat Database) , a framework built on SQLite with a SQLCipher encryption layer. Each chat session maps to a table named Chat_<hash>. Database files ( msg_X.db) automatically split when they exceed approximately 240 MB , creating msg_1.db, msg_2.db, etc. The diagram in the article illustrates this sharded, per-session table structure.

Why SQLite Fits WeChat's Mobile Scenario

3.1 SQLite Is a Library, Not a Service

Unlike MySQL (a server process listening on port 3306 with connection pools, user management, and permissions), SQLite is a few-hundred-kilobyte C library with no separate process or network layer. The application calls its C functions directly to read/write a local file. A mobile app cannot afford the memory and CPU overhead of running a full database server; it needs an embeddable, on-demand engine—exactly what SQLite provides.

// SQLite usage—direct library calls
sqlite3 *db;
sqlite3_open("msg_0.db", &db);  // open database file
sqlite3_exec(db, "SELECT * FROM Chat_abc", callback, 0, 0);  // execute SQL
sqlite3_close(db);  // close

3.2 Single-File Storage Simplifies Backup and Migration

An entire SQLite database—tables, indexes, data—resides in one .db file. Copying a few files moves the whole chat history between devices or to a PC. WeChat's "Backup & Restore" feature is essentially a file copy. With MySQL you would need SQL dumps, transfers, imports, and version-compatibility handling; SQLite's single-file format works cross-platform and cross-version out of the box.

3.3 FTS5: The Secret Weapon for Instant Search

Traditional LIKE '%keyword%' scans every row and becomes unusable at scale. SQLite's built-in FTS5 extension uses an inverted index mapping terms to document IDs, so search hits the index instead of scanning the table. Benchmark : on 10,000 long-text records, FTS5 median latency is 0.14 ms , roughly 15× faster than LIKE. WeChat's chat search (e.g., "Zhang San invoice") leverages FTS5 to locate messages among hundreds of thousands in milliseconds.

WCDB: Tencent's Enhancements on SQLite

WeChat does not use raw SQLite; WCDB adds three critical layers:

SQLCipher encryption : macOS WeChat uses AES-256-CBC with a 32-byte key. Even with the .db file, data is unreadable without the key.

Performance optimizations : batch writes for high-frequency small messages, connection-pool management for concurrent chat windows, and built-in monitoring to detect slow queries.

Multi-thread concurrency coordination : SQLite natively supports only single-writer, multiple-reader (writes serialize). WCDB coordinates at the application layer so reads/writes from different chat windows block each other as little as possible.

SQLite's Ceiling: Where It Stops Working

5.1 Write Concurrency Limit

Even with WAL (Write-Ahead Logging) allowing concurrent reads during writes, writes remain serialized . On a phone this is fine—a single user cannot generate thousands of simultaneous messages. On a server handling millions of concurrent users, SQLite would bottleneck.

5.2 No Network Layer, No User Management

SQLite assumes a single application accesses the file; it has no network protocol, authentication, or authorization. These are non-issues on a phone where the app is the sole client, but they disqualify SQLite as a server-side database.

Architectural Lessons from WeChat's Choice

Not all data belongs in the cloud. Cold data (rarely accessed) stored locally; hot data (frequently needed) in the cloud. This tiered strategy drastically cuts cost.

Embedded databases are vastly underestimated. SQLite deployments likely exceed all other databases combined—phones, browsers, IDEs, countless apps.

Encryption is a baseline, not an option, for local sensitive data. Device loss = data leak. WeChat uses SQLCipher + AES-256; any app storing private data locally must do the same.

SQLite Pros and Cons

Pros

Zero configuration, zero ops—no server process to install, configure, or start.

Single-file, cross-platform—one .db works on Windows, macOS, Linux, iOS, Android.

Full ACID transactions—atomicity, consistency, isolation, durability; crash-safe.

Built-in FTS5 full-text search—15× faster than LIKE.

Tiny memory footprint—engine is a few-hundred-KB C library.

Encryption via SQLCipher (AES-256).

Cons

Single-writer concurrency—write/write serialization; unsuitable for high-concurrency write workloads.

No network layer—cannot serve remote clients.

No user/permission management.

Performance degrades at TB scale; WeChat mitigates by sharding at 240 MB per file.

Applicability Matrix

Mobile app local storage — Strongly recommended. Used by WeChat, QQ; zero-config embed.

Desktop application data storage — Strongly recommended. Browser caches, IDE local storage.

Single-user data management — Strongly recommended. Personal notes, local knowledge bases.

Embedded devices — Strongly recommended. Resource-constrained environments.

Server-side high-concurrency DB — Not recommended. Single-writer limit blocks high write throughput.

Multi-user network access — Not recommended. No network layer; cannot act as a database server.

Conclusion: Fit Over "Best"

WeChat chose SQLite not because it is universally "better" than MySQL, but because it fits the local-storage scenario : zero-config, single-file, ACID, full-text search, and minimal resource use—all without adding server-side storage cost. The trade-off is no cloud roaming; users must migrate manually, and lost devices mean lost history. WeChat accepts that cost. For any system needing local data storage, SQLite deserves serious consideration—it may not be the flashiest choice, but it is often the most pragmatic.

References

SQLite Official Documentation : https://www.sqlite.org

SQLite When-to-Use Guide : https://www.sqlite.org/whentouse.html

WCDB Open-Source Project : https://github.com/Tencent/wcdb