localForage size limit

Hi,

I’ve been trying to find the cap of storage when using localForage with an ionic app. The app I’m developing will have quite some images on it, so I was thinking of encoding the images in base64 to store them with localForage. I’m a little worried about how much data I can store.

Does anyone know the actual cap limit for localForage, I couldn’t find the info on their github and while some people says the cap is 5mb I’ve read other post that says otherwise.

Thanks in advance.

1 Like

If you have many images (and they are large in binary)… base64 is never a good idea because you gain massive overhead.

Localstorage or Forage is never good to store images or heavy data.
Is more to store critical data like for authentication and so on.

If you need to store images offline use something like https://github.com/sunsus/ngImgCache.
Or build something on your own with the file and file-transfer plugin of cordova to download and manage files on filesystem base.

If you need to store many userdata you have the posibility to use the sqlite cordova plugin. there you can structure your data and perform fast queries like simple searchs, paging and so on.

Thanks, I will take a look to the plugin.

My guess by your comment is that localForage does have a cap of 5mb, right?

I Disagree with @bengtler saying Local Forage is bad for heavy data. Before I start I will say averagely and I have no facts I consider heavy data to be in the range of say 100mb - 200mb+ for an app. As shown here http://www.html5rocks.com/en/tutorials/offline/quota-research/ , only the LocalStorage driver is the one you should avoid as it is 5mb. Indexed DB is great as it has unlimited storage. This is pretty much about the same for Web SQL. I can confirm I have tested these 2 and my app uses around 200mb of base 64 images (I Know it has around 100 + images) on 2 separate Angular-Local Forage DB and no issues.
@raymondcamden did a test recently here http://www.raymondcamden.com/2015/04/17/indexeddb-and-limits where he got gigabytes with Indexed DB.

My vote is use it but you can also use something like Pouch DB with SQLite. The advantage of LocalForage over PouchDB for me is that it lets you see the data while debugging in the browser . With SQLite/PouchDB this is not possible since the data lives in the native container.

SIDE NOTE: Always use WebSQL driver for IOS as Indexed DB is dodgy never use it on IOS. Angular LocalForage makes this easy with Ionic. Also I have a project i use with Local Forage & Angular Localforage to automtically store images in an isolate DB https://github.com/saniyusuf/imagenie :slight_smile:

4 Likes

@saniyusuf
good to learn something new… back in my days websql and indexedDB where instable as hell ^^
But i am really not a friend of storing base64 images or blobs in dabasesystems and would prefer the filesystem instead.

Yes you can do this on the file system. But it does not really give any advantage. To be honest I prefer Indexed DB as it is asynchronous and also has so many features. Base64 only adds around 30% overhead but the gains are great since its just a string. It all comes down to choice but if you asked me I will go for local Forage then second choice is Couch DB then File System. File system probably is a very tiny weny bit faster but i find it a bit complex of an API . But yes it all comes down to choice.

@saniyusuf I agree with @bengtler, images should not be stored in DB systems unless we’re talking about databases intentionally created to store BLOB’s and CLOB’s. There’s no real benefit of storing images as string data (BASE64) or binary (blobs).

Just because you can do something doesn’t mean you should do that.

1 Like

yeah i do no like base64 at all… it is not an advantage if you have huge images and lists because you can make the dom explode^^.

But everyone can use what they prefer… but i telling you my concernings…

True this but I like the simplicity of base 64 as they are just strings and you can store strings anywhere plus it reduces the complexity of decoding and encoding blobs. For me this is very key