Dev Build Log
Why We Moved Capture History from sql.js to Native SQLite
The pitfall: long proxy sessions wore us down before the machine did
DevPeek is meant for debugging, not “capture three requests and quit.” Many people leave the proxy on while a phone or WebView keeps sending traffic—thousands of rows in the list, scrolling back to something captured hours ago in the Debug tab.
Since v1.1.4, capture history is saved locally so you still see recent traffic after restart; script-processed headers and bodies are kept too. Collaboration messages, Debug tab Network entries, and resend history also needed to stick around.
At first we used SQLite compiled to JavaScript (sql.js, common for in-browser storage). Easy to wire up, no native OS pieces—fine while the feature set was small.
Once real debugging sessions got busy, the cracks showed.
What it felt like: heavier and heavier—“time to restart”
If you’ve seen any of this while using DevPeek, it was likely the same class of issue:
- Proxy on from morning to evening, the app feels slower, memory in Task Manager creeping up.
- With a long list, paging, search, and opening details hiccup now and then while Mock and breakpoints still run—like the whole machine is dragged along.
- You start treating “quit DevPeek when done” as “restart because it’s been up too long.”
On our side the cause was: sql.js keeps the whole database in memory. Every new capture and every detail update meant copying an ever-larger database to disk on a timer—like photocopying a notebook that gets thicker every hour.
More captures and fatter headers/bodies meant slower copies and higher memory spikes. The proxy was still decrypting HTTPS, running Mock, and holding breakpoints—lag stacked on lag.
The list could paginate and filter, but underneath it was still “big blob in RAM, periodic full flush”—not “append one row to a file on disk.” As we added param transform, page debugging, and collaboration, this wasn’t fixable with small tweaks—we had picked the wrong storage model.
What we changed: native SQLite for all-day runs
We migrated capture and collaboration storage once, from sql.js to native SQLite—the same kind of local database the OS uses, written straight to disk through a native module.
The goal was simple: performance and memory. DevPeek should run continuously all day with no memory pressure.
After the change, writes work differently:
| Before (sql.js) | Now (native SQLite) | |
|---|---|---|
| Where data mostly lives | RAM, growing | Local database files |
| How saves work | Periodic full copy to disk | One row at a time, patch in place |
| All-day sessions | Memory climbs, occasional freezes | Flat memory, responsive list |
Proxy on all day, list still scrolls, Mock still clicks—without restarting out of habit because it’s getting sluggish.
Native modules cost us extra packaging work each release—we pay that because DevPeek is meant to sit in the background through a full debugging day, not choke on storage.
What you should notice after the change
- More history kept: per-database capture cap went from about 1200 to 5000 rows (oldest still trimmed so it doesn’t grow forever).
- Separate stores per feature: capture, collaboration, Debug Network, and resend history don’t drag each other down.
- Long sessions with less worry: the pitfall we hit was memory and lag over time; after the storage swap we can honestly say DevPeek is built to stay up all day.
If an older build felt like “gets slower until I restart,” try a current version on a long session. Still seeing issues? GitHub Discussions—roughly how long you leave it on and how many rows in the list helps us compare notes.
For how the capture list and history work, see Capture & filtering. Download DevPeek and leave the proxy up through a real debugging day.