Memory Retention Issue: Deleted Documents Still Occupy Space on the Device

Hello everyone,

I’ve encountered a problem with Couchbase Lite that I’d like to address. It appears that when documents are removed from the Couchbase server and the changes are synchronized with the mobile device, the device’s memory doesn’t decrease as expected. Even though the deleted documents are no longer visible to the user, the memory space they previously occupied remains allocated. This situation could potentially pose a concern, particularly for users who deal with a substantial volume of synchronized data, as it could result in the rapid consumption of storage on the mobile device. This issue is observed on both Android and iOS devices.

There are several kinds of “memory” on a device and I am not clear about which one you mean. Perhaps you are talking about the size of the database file? If so, there is an API call: Database.performMaintenance(MaintenanceType.COMPACT) that will minimize the amount of file system space that the database uses.

Compaction is quite an expensive operation and we, like most systems that use SQLite, do it only when necessary. Although, certainly, db size is a potential problem, only rarely have we seen it be an actual problem.

Blake is right. More details:

  • The space left behind in the db file will be reused by other documents.
  • The database is incrementally “vacuumed”, so over time the free pages will be moved to the end of the file and the file truncated.

Hi Blake, appreciate your response.

I’m specifically referring to the device’s physical storage, like the SSD or HDD.

I’ve already tried using the performMaintenance(.compact) function, but unfortunately, it doesn’t bring down the data size on my device to its initial state. For instance, if the app size is 1GB, after adding a document it goes up to 1.1GB. Even after deleting the document, there’s no change. Running the performMaintenance function reduces it to 1.095GB, but it’s still far from the app’s initial state before adding the document. Any insights or suggestions on resolving this would be greatly appreciated.

Jens, when you say “pages will be moved to the end of the file and the file truncated”, does it mean it will free up the space on the disk? What is the approximate time for pages to be “vacuumed”?

I think the only insight I can provide is that you will have to expect that a working database will have some small space overhead.

1 Like

How are you measuring the size? It would help if you could get the exact size of the database (the “xxx.cblite2” directory.) You can either do this in the Simulator and then locate the app’s storage in the filesystem, or you could use NSFileManager or equivalent to find its size and log it.

I’ve been measuring the size of my app in the device settings, where I can see both the app size and the data size. I’ve noticed that the data size changes after adding a new document but doesn’t change after deletion.

Regarding your mention of the database being incrementally ‘vacuumed’ and free pages being moved to the end of the file “over time”, could you clarify how long this process takes? Additionally, does this mean the space will eventually be freed up, or is it reserved for database usage?

Incremental vacuum runs during Database.close() and moves a limited number of pages around so it won’t take too long to run. As pages get moved away from the end of the file, free pages will collect there and SQLite will truncate the file.

An explicit vacuum command via Database.maintenance will run as long as it takes to move all free pages to the end and truncate the file.

There’s not any more advice/troubleshooting I can offer unless you can get a copy of the database out of the device and look at it with a tool like our cblite or the standard sqlite3 tool.