CAPACITY AND PERFORMANCE

SQLite limits: what matters in practice

SQLite can store far more data than many people expect from a database contained in a file. Its published upper bounds are useful for understanding the engine, but they are not a promise that every device, browser or query can handle a database near those limits. Disk space, indexes, transaction patterns and available memory usually matter first.

Database size is not the same as usable workload

SQLite stores a database in pages. With the default 4 KiB page size and current default page count limit, the documented maximum file size is about 17.5 TB. A build using the maximum 64 KiB page size can theoretically reach about 281 TB. Those are engine limits, not target sizes for a web browser. Filesystems, storage capacity and application configuration may impose lower limits; actual performance depends on what the application reads and writes.

The documented theoretical maximum is 264 rows per table, but the maximum file size is reached first. In ordinary projects, a table with millions of rows is more likely to be constrained by a missing index or a query that loads every row than by SQLite's row-count ceiling. Inspect the query plan, add indexes for important filters and joins, and paginate results instead of drawing the entire table at once.

Memory depends on work, not just file size

SQLite uses memory for connections, prepared statements, page caches, sorting and temporary results. A small database can use substantial RAM for a large sort; a much larger indexed database may answer a selective query using comparatively little. Measure the full application process with representative data and queries. Keep write transactions short if other connections need to write to the same file.

SQLite Lab adds its own browser-side limits to keep the workspace responsive: result previews are bounded, temporary database imports are capped at 100 MiB, and exports have format-specific limits. A saved database, an in-memory copy and a download may also consume different amounts of device memory. For important data, download a backup and test on the actual devices you plan to use.

Choose the right next step

For a slow query, start with the SQLite query-plan explorer and review indexes. For write contention, read the database locked guide. If several servers need to write to one shared database, compare SQLite and PostgreSQL. The exact engine ceilings and compile-time settings are documented in theofficial SQLite limits reference.

HELPFUL ANSWERS

Frequently asked questions

Clear answers to common questions about this topic.

How much RAM does SQLite use?

There is no fixed RAM requirement for every database. Memory use depends on page cache settings, active connections, prepared statements, query sorting, temporary tables and application buffers; the database file size alone does not determine RAM use. Measure the whole process under representative queries. In a browser, available memory and worker buffers also affect practical limits.

How many data can SQLite handle?

SQLite has large theoretical limits, but practical capacity depends on disk space, page size, indexes, query design and application memory. Its documented maximum row count is 2^64 per table in theory, far beyond normal hardware. Test your actual database size and workload, keep backups, and avoid assuming a browser can load any arbitrarily large file.

How many rows can SQLite handle?

SQLite documents a theoretical limit of 2^64 rows in a table; real limits are reached much sooner through file size, storage, indexes and query performance. A million rows is not inherently a problem for SQLite when queries are indexed and results are paged. For browser tools, device memory and import/export strategy impose additional limits.