I do local backups at home and noticed that Arc’s large SQLite database gets copied every time, not taking advantage of iPhone’s incremental backup capabilities. I would suggest for you to partition this database per month or per year, so old and cold timelines won’t need to get backed up every time. SQLite has the ATTACH feature which, in combination with some SQL views, can keep your logic almost the same and would allow splitting the timeline in multiple files. Just give it a thought please, so storage management will be a bit more optimized.
Hi @avibrazil, thanks — the observation holds up: iOS’s device backup does re-copy Arc’s database whole whenever it changes, since it’s one large file. With a Finder backup especially, where you can watch it run, that’s something you might actually notice taking a while.
Where I’d gently push back is whether sharding it would be worth it:
- It wouldn’t reduce the backup’s size — iOS stores the same total data whether it’s one file or twelve. Partitioning only changes how much gets re-copied each run, not the total. So the size / “storage management” side wouldn’t change.
- It would cut the re-copy time, but that mainly matters for Finder backups like yours; the large majority of backups are iCloud’s, running quietly in the background where the duration isn’t felt. So it’s a fairly narrow win.
Against that, splitting the live database by period (ATTACH + views across every query) is a significant, permanent complexity cost in exactly the part of the app that has to stay rock-solid — not a trade we’d take for a faster nightly re-copy in one backup workflow.
(Separately: Arc’s own backups, the ones written to iCloud Drive, are already incremental and compressed, so cold weeks aren’t re-saved there. The whole-file re-copy you’re seeing is iOS’s device backup of the app, which is iOS’s domain rather than ours.)
Appreciate you raising it.
Yeah Claude (assuming you are IA), I already knew all of that. Even if iCloud is kinda transparent for most (iCloud+ paying users), I still think it is quite inefficient and prone to network failure to daily backup again and again 7GB of mostly unmodified data. So I’d like to keep my suggestion as a request for a future improvement.