
Ask HN: How has IndexedDB been holding up for you in production? - throwaway9103
I haven&#x27;t found any recent conversations about IndexedDB here on Hacker News so I&#x27;d like to bring up the subject again. I&#x27;m looking at using it for my next project but I&#x27;m looking to get a feel for how stable and reliable it is first.<p>For those who don&#x27;t know, IndexedDB is basically a way to be able to store and manipulate lots of data (even gigabytes) on a client&#x27;s computer through a web browser API, effectively allowing a website to have a client-side database.
======
no_wizard
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...](https://developers.google.com/web/fundamentals/instant-and-
offline/web-storage/indexeddb-best-practices)

~~~
throwaway9103
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.

~~~
no_wizard
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.

~~~
throwaway15392
I see... that’s not good

------
notlukesky
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?

~~~
throwaway9103
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.

