Memory Leak for the SQLite

[stackedCG]

Hi is there any sort of reported leak for SQLite plugin? Whenever I communicate with the SQLite plugin, I noticed that the memory stacks up bit by bit, and it never went down, also is there a way where to clear the memory myself whenever I communicate in SQLite, since I noticed that there are also some issues from other threads regarding memory leak that was never closed as far as I know.

Thanks in advance.

[stackedCG]

Hi team, just want to follow up on this, thank you!

[manimovassagh]

SQLite memory growth in Tauri is a common concern but usually not an actual leak — it is SQLite's page cache doing its job. Here are the most likely causes and fixes:

1. WAL mode page cache growth

If you are using WAL mode (the default for the Tauri SQLite plugin), SQLite keeps pages in memory to serve reads without hitting disk. The cache grows up to cache_size pages and stays there. This looks like a leak but is expected behavior.

You can cap it:

PRAGMA cache_size = -2000;  -- limit to ~2MB

Run this right after opening the connection.

2. Unreleased prepared statements

Every prepared statement holds references to cached pages. If you are building queries dynamically without finalizing them, memory accumulates. Make sure you are not holding onto statement handles longer than needed. If you are using the tauri-plugin-sql JavaScript API, each execute() / select() call should finalize automatically, but if you are calling the Rust rusqlite layer directly, make sure statements are dropped.

3. Periodic cleanup

You can periodically reclaim memory:

PRAGMA shrink_memory;

Or from Rust:

conn.cache_flush()?;

4. WAL checkpointing

The WAL file itself can grow if it is never checkpointed. Force a checkpoint to reclaim disk and associated memory:

PRAGMA wal_checkpoint(TRUNCATE);

5. Profiling

To confirm whether it is actually SQLite or something else, monitor PRAGMA cache_hit / PRAGMA cache_miss and check your process memory with a tool like Activity Monitor or top. If memory keeps growing even after shrink_memory, the leak is likely on the JS/WebView side (e.g., large result sets being held in JS variables).

The open issues you mentioned are mostly about the WebView's own memory management rather than SQLite itself. Worth distinguishing between the two.