# DBRepair development **URL:** \ **Category:** Apps & Creations\ **Created:** [December 14, 2022, 3:57am UTC](https://forums.plex.tv/t/dbrepair-development/822684 "2022-12-14T03:57:23Z")\ **Posts on this page:** 1\ **Showing post:** 379
**Author:** ![Volts](https://avatars.discourse-cdn.com/v4/letter/v/a5b964/32.png) [@Volts](https://forums.plex.tv/u/Volts)\ **Post date:** [January 17, 2024, 9:02pm UTC](https://forums.plex.tv/t/dbrepair-development/822684/379 "2024-01-17T21:02:54Z")
I saw a significant _drop_ in performance when pagesize exceeded a certain size. 4096 was an undeniable win. 8192 and 16384 were better only with tons of cache available to SQLite. 32768 and 65536 were worse. > [@Database Cache Size Behavior Question](https://forums.plex.tv/t/database-cache-size-behavior-question/822657/7): > > And a few more for comparison. Again I acknowledge that this isn’t the same as being inside Plex. slight_smile This is all speedtest1, new files each time, varying the page\_size and cache\_size only. # Variants of this command: rm testfile.db ; ./speedtest1 --size 200 --journal WAL --pagesize 1024 --cachesize 2000 testfile.db | grep TOTAL 1024, 2000 = 2048000 TOTAL....................................................... 55.506s 1024, 4000 = 4096000 TOTAL......................… That was all on a filesystem with the default ZFS recordsize of 128k. --- _[View the full topic](https://forums.plex.tv/t/dbrepair-development/822684)._