Hi, just a “simple” and curious question. How much space is available on mobile devices? If my SB Vault grows to 5GB for example, is something my phone browser storage can manage?
Regards.
Hi, just a “simple” and curious question. How much space is available on mobile devices? If my SB Vault grows to 5GB for example, is something my phone browser storage can manage?
Regards.
This is what Claude.ai says:
Update: this seems to be hallucination, see below.
The storage limits for IndexedDB in mobile browsers vary by browser and device, but here are the general guidelines:
Uh, thanks, this maybe could be not too much for larger vaults.
Thinking about this, and knowing v2 comes full sync mode, what will happen with vaults bigger than this values?
Also what about assets such as images, pdfs, etc. that are stored in the space? Are they synced to each client as well? That could significantly increase the space size. What if we could make it only sync text based content and dynamically load binary data from server as need? Does that happen now?
This is exactly one of the reasons that gives Anytype -1 points right now for me. I want full sync offline access.
An example. You sync your phone from computer, several pages with images, files and so on. Then, you go to take a flight and need for example a document inside the vault (booking ticket or whathever). Then notice you see file is not there, because you didn’t requested when you had connection with the host. This is not local first for me, because I need available 24/7 a server with my vault.
Sync mode syncs everything right now, also attachments/documents.
Sorry not clear - does this mean we can’t have >50MB spaces?
Yes. If the limit is indeed 50mb. That said, I think it should be quite possible to opt out of syncing attachments and documents, so just pages. I’d have to think how to exactly implement that, but should be doable.
I can see even markdown pages by themselves could start hitting the 50MB limit without attachments. Would it be possible to force the browser to evict old entries based on last accessed date? I then pull in new copies if requested by the browser? You would then have offline access to your most often used pages which is normally what you want anyway.
Hi @zef , I think this is an important issue which I suspect many will want reassurance on. If SB is a 50MB PKM, many will I suspect decamp to other systems. I suspect you’re working on a solution to this, but I for one would be grateful for such reassurance.
Thanks
Nick
Ok, if this is a concern for people, I’m now looking this up on MDN rather than taking the risk of Claude hallucinating things:
Safari
Starting with macOS 14 and iOS 17, Safari allots up to around 20% of the total disk space for each origin. If the user has saved it as a web app on the Home Screen or the Dock, this limit is increased to up to 60% of the disk size. For privacy reasons, cross-origin frames have a separate quota, amounting to roughly 1/10 of their parents.
So this would suggest significantly bigger limits than 50MB for iOS, especially when adding SB as a home screen app (like you should ), this should be multiple GB in practice.
For Chrome browsers:
In browsers based on the Chromium open-source project, including Chrome and Edge, an origin can store up to 60% of the total disk size in both persistent and best-effort modes.
For example, if the device has a 1 TiB hard drive, the browser will allow an origin to use up to 600 GiB.
And Firefox:
In Firefox, the maximum storage space an origin can use in best-effort mode is whichever is the smaller of:
- 10% of the total disk size where the profile of the user is stored.
- Or 10 GiB, which is the group limit that Firefox applies to all origins that are part of the same eTLD+1 domain.
Origins for which persistent storage has been granted can store up to 50% of the total disk > size, capped at 8 TiB, and are not subject to the eTLD+1 group limit.
For example, if the device has a 500 GiB hard drive, Firefox will allow an origin to store up to:
In best-effort mode: 10 GiB of data, which is the eTLD+1 group limit.
In persistent mode: 250 GiB, which is 50% of the total disk size.
Not sure if Firefox has different behavior on Android, but this also seems plenty.
Thanks @zef that sounds promising, how need to find a usb cable for my iPhone to run
navigator.storage.estimate().then(console.log);
in a remote debugging session to confirm.
In Edge on MacOS I get 282889 MB which is comfortable (!).
Handy snippet:
navigator.storage.estimate().then(({ usage, quota }) => {
console.log(`Used: ${(usage / 1024 / 1024).toFixed(2)} MB`);
console.log(`Quota: ${(quota / 1024 / 1024).toFixed(2)} MB`);
console.log(`Usage percentage: ${((usage / quota) * 100).toFixed(2)}%`);
});
You should be able to access this in Lua via js.window.navigator which you can then editor.flashNotificarion
${js.window.navigator.storage.estimate()}
returns
Usage: 97101065
Quota: 38654705664
There you go
Hmm, might have spoken too soon, ChatGPT 4o (ChatGPT - Mobile IndexedDB Limits) says that the 36GB is the quota across all origins, iOS Safari silently caps IndexedDB at ~50MB per origin.
That’s what Claude said. But is it true? What’s the source of this information and is it still valid in 2025?
If assets are also synchronized (i suppose they are?) I’d dd if=/dev/urandom of=test.png bs=1M count=60
and drop the file into some test instance and see what happens when you visit it in Safari on mobile.