SQLite Limits

~10 min · limits, scale, production

Level 0Scout

0 XP0/80 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

The numbers that surprise nobody (because they're huge)

SQLite's hard limits are far beyond what most applications hit. The ones to know:

Database size — 281 TB (2^48 bytes). The page-size × max-page-count product. Default page size 4096 × max 4.3 billion pages.
Row size — ~1 GB per row. Practical limit much lower for performance.
String/BLOB column length — defaults to 1 GB, configurable.
Number of columns — 2,000 by default; recompile to raise.
Tables per database — billions, no practical limit.
Concurrent writers — one at a time per file. This is usually the limit you hit, not size.

Tip: If you're worried about a SQLite size limit, you've almost always run into the single-writer limit first. Plan around that — sharding by tenant, batching writes, separating hot and cold data — long before you worry about the 281 TB ceiling.

Code

Inspect the practical limits in your build·sql

PRAGMA page_size;
PRAGMA max_page_count;
SELECT page_size * max_page_count AS max_db_bytes FROM
  (SELECT 4096 AS page_size, 4294967294 AS max_page_count);
-- 17,592,186,040,320  (~17 TB — increase max_page_count for more)

External links

Implementation Limits For SQLite

Exercise

Read the implementation limits page. For one product you work on, identify which (if any) limits would actually constrain you at 10x current scale. Most projects find none — write down the actual bottleneck instead (write throughput, query latency, deployment shape) and what you'd change to address it before SQLite became the issue.

Progress

Progress is local-only — sign in to sync across devices.

← PreviousFile Locking — The OS Layer Next →Testing Strategies — In-Memory and Fixtures

Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)

No comments yet — be the first.