IndexedDB Access Speed and Efficiency

Question

I'm developing an RPG in Dart, and I'm going to use IndexedDB for data persistence.

I will have two databases: one for read-only access and one for read-write access where save games will be stored. I was just wondering if I should read required data directly from the database or cache it in Maps. I could potentially have several hundred records that need to be pulled from the read-only database (enemies, game maps etc.) and I though pulling everything from the database may be less efficient than using Dart's Maps.

Oh, also each database will be stored in a map. Object Stores will be nested maps inside that map.

Should I read directly from the database, or should I put everything into a Map and read from there?

EDIT: Forgot to mention, the read-only database will be initialised with data from a JSON file located on the user's machine, not through AJAX.

Answer 1

I am confident that hundreds of records will present you no issue in IndexedDB. IDB was designed with that kind of scale in mind, and its async APIs -- while vexing for novices -- make sure your app stays responsive by design.

I am working on a demo designed to push IDB further than it should go, and have some easy-to-reach statistics for you. These are gets on a single index in a single store on a database.

Gets are blazing fast in IndexedDB. The issue with IDB at scale is typically writes.

One thousand success callbacks, one complete callback, were sub-second:

Ten thousand success callbacks, one complete callback, was about 5 seconds:

More than fifty thousand success callbacks fired in less than a minute:

Writes are much slower - bursty at first, but then slow after minutes and dog slow after hours. That's with any schema, but you'd likely have multiple indexes on location (both latitude and longitude at least, I imagine) so your writes will be especially slow (more indexes, more work to do to main those in inserts and updates).

Layout for the stats above (just as important as the stats themselves, make sure to design your schema according to how you need to access it):