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.
Ask HN: How has IndexedDB been holding up for you in production?
1–9 of 9 posts
Re: Ask HN: How has IndexedDB been holding up for you in production?
#2By the way are there any similar projects that already use it at all?
Re: Ask HN: How has IndexedDB been holding up for you in production?
#3What 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?
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.
Re: Ask HN: How has IndexedDB been holding up for you in production?
#4What 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?
Re: Ask HN: How has IndexedDB been holding up for you in production?
#5It 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...
Re: Ask HN: How has IndexedDB been holding up for you in production?
#6I’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…
Re: Ask HN: How has IndexedDB been holding up for you in production?
#7I’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…
Re: Ask HN: How has IndexedDB been holding up for you in production?
#8I’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…
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.
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.
Re: Ask HN: How has IndexedDB been holding up for you in production?
#9Earlier quoted context omitted.
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.