> IndexedDB can store a huge amount of data ... In most cases that would be gigabytes.

You are of course right, but it's always good to surface pathological worst-case scenarios as interesting counterbalances.

IndexedDB has really, really REALLY bad performance. It's like a turtle that's been trapped in molasses. I did some benchmarks on my (old) laptop here: https://stackoverflow.com/questions/42288596/websql-has-incr...

For a particularly rare edge case, I periodically have to SIGKILL Chrome so it doesn't crash (due to failed SQLite assertions) when my disk gets full and I have to shuffle things around to make space. In the last instance of this taking place, / had 820KB free.

(Context would probably be useful here: I have a 15+-year long diskspace issue created by being given many many old computers with tiny hard drives and not having the infrastructure/knowhow (when I was younger) to move/sync active projects between machines. I just need to get a couple large HDDs so I can collect and dedupe everything, but I can't work due to health issues so that's proving... fun. This is also blocking all kinds of things such as getting my first smartphone, so I have nowhere to back it up onto!)

You've got no contact details in your profile but in the very small chance that you're in Australia, I've got a number of spare hard drives I could give you.

There are a surprising amount of Australians here I have noted.

It depends when you frequent HN -- timezones make it fairly easy to spot us.

Uhh, wow. :)

Hmm. If I'm reading right it looks like I'm slightly north of you, in Sydney.

Been meaning to add something to my profile. Done.

I'll endeavor to get in touch soon. This is pretty cool.

I just re-ran your test suite[1], and I got 1.325s insertion time with 10k items on IndexedDB on Chromium on GNU/Linux (with lots of tabs open). I'm on a fairly modest 8-core 16GB box. It's still 1 order of magnitude slower than the others, but not as bad as your old results.

I'll try running it on my X220 later.

[1]: http://scaljeri.github.io/indexeddb-vs-websql/v2.0.0/index.h...

Hmmmmm.

Either that specific test (I didn't make it, to clarify) or Chromium has a bug.

Depending on how I fiddle with the browser, the test either takes 134 seconds or 6 (!!!) seconds.

Of course when I ran the test for the first time I did it a few times. I think the repeated tests may have triggered these bugs.

If I go to the test page, click the (i) to the left of the domain, hit Cookies, select the domain (the root of the tree listview) and Remove (to remove the IDB, WebSQL and localStorage bits the page sets up) and then run the test, I consistently get 6 seconds.

My suspicion is that, the page is creating 1000 items in localStorage, THEN adding my 10000 on top of that. That would explain the crazy delays.

However, this does not explain why, when I visited the page for the first time in several months, it completed in 6 seconds without any tinkering required.

Note that the page re-fills localStorage on each load - clearing it after the page has loaded is key.

They specifically only support Chrome from what I read.

"Works best with IE 6" is so old now you'd think tech folks would think twice.

"Works best in IE 6" wasn't dumb at the time. It was the best browser available. What was bad is those sites continued to work only in IE6 long after it ceased to be the best browser.

The browser ecosystem is much healthier now. If Chrome ceases to innovate there are others ready to take over.

A valid test if Superhuman is for power/business users, is can it handle 5-15 years of email history that's currently in one inbox?