Excessive storage is consumed when inserting IndexedDB data. It seems to depend on volume and transaction size. e.g. saving 500MB worth of simple text data will result in a consumption of 1350MB of storage. This behaviour can be reproduced easily in Safari; 1) Check storage & note consumption value (Settings>General>iPad Storage>Safari : Documents & Data) 2) Visit https://demo.agektmr.com/storage/ and insert ~500MB worth of IndexedDB data as 1000 x 500.0KB chunks 3) Accept any additional storage request prompts 4) Check storage consumption value again If this doesn't reproduce the issue, try different chunk sizes (e.g. 10000 x 50KB) Tested on A1709 iPad Pro iPadOS 13.3.1
<rdar://problem/59950145>
This site appears to add X rows that are each Y MB in size to a table with no indices and an auto-incrementing primary key. (In the bug report X = 1000 and Y = 500 KB => 500 MB of expected disk usage.) I can't repro excessive disk space usage when using an erase-installed 17D50 (iOS 13.3.1) device. What I do see is that the WAL file does not checkpoint properly into the main DB file since it is 500 MB large after running the test: -rw-r--r-- 1 mobile mobile 4.0K May 8 14:19 IndexedDB.sqlite3 -rw-r--r-- 1 mobile mobile 1.0M May 8 14:21 IndexedDB.sqlite3-shm -rw-r--r-- 1 mobile mobile 512M May 8 14:21 IndexedDB.sqlite3-wal Inserting a subsequent 10k rows each 50KB each does bring up the storage prompt, but that is expected since the additional 500 MB of usage on top of the existing 500 MB puts you over the default 1 GB quota for per-origin storage usage. The issue with the WAL file not checkpointing can lead to excessive space usage and has been fixed in https://bugs.webkit.org/show_bug.cgi?id=202137.