Ask HN: How has IndexedDB been holding up for you in production? | Hacker News Reader

Ask HN: How has IndexedDB been holding up for you in production?

I haven't found any recent conversations about IndexedDB here on Hacker News so I'd like to bring up the subject again. I'm looking at using it for my next project but I'm looking to get a feel for how stable and reliable it is first.

For those who don't know, IndexedDB is basically a way to be able to store and manipulate lots of data (even gigabytes) on a client's computer through a web browser API, effectively allowing a website to have a client-side database.

View on HN

I’ve used it. There isn’t much to discuss honestly. It’s a bit faster in my experience than local storage is, and it can handle more than just string types natively (like ArrayBuffers).

It also has a concept of versioning that’s really clean.

However, all your data is dead if you ever clear your cache or migrate machines. You should really consider that as a huge downside. Databases have an important use case and you don’t have to just use a SQL solution either.

Something like CouchDB would work fine if you only want some Storage. PouchDB + CouchDB is a good combo That would give you some nice abstractions here without having to put all the onerous on the end user to have some continuity in their data

Also see https://developers.google.com/web/fundamentals/instant-and-o...

Thank you for your input. I recall reading somewhere before about a chrome update that (accidentally?) wiped out data stored through indexeddb. Have you heard or experienced anything like this? That case is more concerning to me than when a user clears their own data, because any copies of the data across many machines would all be wiped out around the same time.

I’ve experienced updates in every browser go awry in this way one way or another.

It’s really built to be a source of ephemeral storage not the sole provider for an application, that’s just the reality of it. There’s no continuity guarantees.

I see... that’s not good

What is the reason you think you would need to use it on your next project?

By the way are there any similar projects that already use it at all?

To avoid having a centralized database altogether and just have clients store their own data on their own machines.

The reasons why I'm interested in that are:

1) security and privacy (much harder to steal data that's not centralized in one place, and I'll be able to sleep better at night knowing I don't have sensitive data on my hands)

2) code maintainability. I'm not impressed with what happens behind the scenes with relational databases out there and I think it stems from tackling the problem at the wrong layer of abstraction. basically relational databases nowadays aren't really just databases, they're also ways for many, many users, even millions sometimes, to reach consensus about what the current state of the data is. and to throttle alllll those data changes from all those users through one current state (the database) is just wrong imo. really, every user should have their own state of the data, and whenever one user makes a change to their data, that change can be communicated across the network. i.e. a p2p database. this i think decouples storing and manipulating data from communicating data changes.

Reply on news.ycombinator.com