Web Storage APIs

Data Storage APIs Comparison

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Web Storage APIs

Check out a free preview of the full Web Storage APIs course

The "Data Storage APIs Comparison" Lesson is part of the full, Web Storage APIs course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano compares the type of content stored, key usage, grouping, and storage limits of the previously discussed data storage APIs.


Transcript from the "Data Storage APIs Comparison" Lesson

>> In terms of comparison, let me go quickly over this chart. So IndexedDB stores JavaScript objects and binary data. Cache storage stores HTTP responses. So a PNG file, a JavaScript file, an HTML file, a PDF file. Web Storage, both session and local, are storing strings, just strings. It's also very limited.

So if you have ever used a web storage or a local storage before, it's just strings. So if you have an array, you have to convert that array into a string like comma separated or JSON stringify, or something like that. So it's limited, okay? And the FileSystem Access is working with files, okay?

Directly text files or binary files, you have the full API to work with a complete file system. So IndexedDB is using a key of a keypath on most situations within the option. What's the keypath? The name of a property in your object that is the primary key, ID, for example, okay?

But it can be name, a path within the JSON, within the object that you are saving within IndexedDB. On cache storage, the key is the request, okay? So that involves the URL, okay, but also it can be cookies, the header, so the whole request is the key. So if you wanna get an object from the cache storage, you need to provide the requests.

And the storage will give you, okay, here you have the response for that request. Make sense? That's the primary key. On web storage, it's another string. So the key is another string. So key value, and both are strings. And for the FileSystem Access, well, we don't have a key, we just have a path, maybe, okay, for the file that we need to open.

On IndexedDB the data, okay, or the JavaScript objects, are grouped in object stores, and object stores are grouped in databases, okay? In the cache storage, it's grouped in caches, that's the name. In web storage, there are no group. They are just at the root level, okay? So you just store keys at the root level, and the same with FileSystem Access.

IndexedDB, you can store JavaScript objects and binary data with the key path grouped in object stores, up to the available quota. And this is the first time we are using that term officially. So, of course, the next question will be, what's the quota? Stay with me, we will see that.

On cache storage, the same. But the web storage, that's not the same. So web storage is not using your available quota. On session storage, it's typically 12 megabytes. And local storage is typically five megabytes. So we don't know what quota is, but let me spoil you this. Typically today, you can safely store up to a gigabyte per origin without any issue on IndexedDB or cache storage.

So five megabytes doesn't seem good enough. So that's another reason of why we don't wanna use local storage anymore. And it's even worse. [LAUGH] I will explain why. So those five megabytes are not really five megabytes. I will explain why in a minute. Okay, so remember I mentioned that if you like SQL databases for whatever reason, there are new ideas today that are coming back.

So do you see when I use SQL, do you wanna create your own API, your own database API? So you feel you have the knowledge to create a high performance database and you wanna create your own IndexedDB alternative? Well, today, thanks to WebAssembly, and IndexedDB, and or FileSystem, it's possible.

So there are currently some libraries that are taking SQLite, for example, that is a C library. So they took the C library, they converted it into WebAssembly module, and then you can run directly SQLite on top of IndexedDB. So then you can still use SQL if you want.

Yeah, you will have probably a performance penalty because you need to load that WebAssembly module, it's not a native module in the browser. But we are talking about the couple of kilobytes, not l huge library. And if you really need SQL for whatever reason, well, maybe you already have a system that works with SQLite, and you already have a really huge structure, and you wanna reuse all the code, all the queries, and everything that you have done on your web app, well, you can do that now.

With WebAssembly, there is a high performance way to run code, client side.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now