AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data roomsImmortalDB
ImmortalDB is a JavaScript key-value store for browsers that redundantly stores data across cookies, IndexedDB, and localStorage, then self-heals by detecting and correcting data loss. It's designed to survive browser storage evictions and user-initiated data clearing while respecting privacy.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | gruns/ImmortalDB |
| Owner | gruns |
| Primary language | JavaScript |
| License | MIT — OSI-approved |
| Stars | 3.1k |
| Forks | 60 |
| Open issues | 39 |
| Latest release | v1.1.1 (2025-04-17) |
| Last updated | 2025-04-18 |
| Source | https://github.com/gruns/ImmortalDB |
What ImmortalDB is
ImmortalDB implements consensus-based storage across three browser APIs (cookies, IndexedDB, localStorage), using plurality voting on retrieval to determine canonical values and automatically syncing discrepancies. It wraps standard HTML5 APIs with a Promise-based get/set/remove interface and supports pluggable storage backends.
Get the ImmortalDB source
Clone the repository and explore it locally.
git clone https://github.com/gruns/ImmortalDB.gitcd ImmortalDB# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- All keys and values must be DOMStrings; complex data requires manual JSON serialization/deserialization.
- Promise-based API requires async/await; ensure error handling for storage quota exceeded or blocked access (e.g., in iframes).
- Redundant writes on every set() operation across three stores; consider performance impact if storing frequently-changing data.
- Storage capacity limited by browser; default stores (cookies ~4KB, localStorage/IndexedDB ~5–50MB) vary by browser and user settings.
- Data visibility: not encrypted by default; all three storage mechanisms are accessible to JavaScript in the same origin.
When to avoid it — and what to weigh
- Storing sensitive authentication data — Cookies, localStorage, and IndexedDB are all accessible to XSS attacks. Do not store tokens, passwords, or PII; use httpOnly cookies for auth at the HTTP layer instead.
- Large-scale structured data — Values must be DOMStrings; complex objects require JSON serialization. No query API, indexing, or transaction support. Use a proper database for complex data models.
- Guaranteed data privacy or right-to-be-forgotten — Redundant storage across three locations complicates complete data deletion. Users may not be aware data persists across storage clearing. Not suitable for GDPR-sensitive applications.
- Performance-critical frequent access patterns — Every get() calls three stores and performs consensus voting. For high-frequency data access, the overhead may outweigh the resilience benefit.
License & commercial use
MIT License. Permissive OSI-approved license permitting commercial and proprietary use, modification, and redistribution with attribution and no warranty.
MIT permits commercial use without restriction. However, verify your use case does not require integration guarantees, support, or indemnification not provided by the MIT license or the library maintainer. Review security and data retention implications for your specific product.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | Low |
| DEV.co fit | Good |
| Assessment confidence | High |
ImmortalDB stores data in three browser APIs, all of which are vulnerable to XSS and accessible to any JavaScript on the same origin. No encryption, authentication, or access control built in. Suitable for non-sensitive data only (e.g., preferences). Not a substitute for httpOnly cookies or server-side sessions for auth. Users may be unaware data persists across storage-clearing actions; privacy expectations should be documented.
Alternatives to consider
IndexedDB (native)
Direct use of IndexedDB avoids abstraction overhead and redundancy writes; suitable if you accept data loss risk and want querying/indexing. More mature ecosystem and browser support.
LocalForage
Abstraction over localStorage, IndexedDB, and WebSQL with fallback; simpler than ImmortalDB if redundancy is not critical. Better browser compatibility and maintenance.
PouchDB
Full sync-enabled database with offline-first design, replication, and query support. Heavier but more suitable for complex data and conflict resolution.
Build on ImmortalDB with DEV.co software developers
ImmortalDB offers resilience through redundancy, but requires careful handling of sensitive data and serialization. Devco can help you integrate it safely into your web application and evaluate trade-offs with alternatives.
Talk to DEV.coRelated on DEV.co
Explore the category and the services that help you build with it.
ImmortalDB FAQ
Does ImmortalDB encrypt data?
Can I store objects or arrays directly?
What happens if all three stores are cleared?
Is ImmortalDB suitable for storing authentication tokens?
Senior engineers for your next build
ImmortalDB rarely ships on its own. As a software development company, DEV.co handles the surrounding work — data modeling, service integration, deployment, and the open-source databases glue code that production actually requires.
Ready to explore persistent browser storage?
ImmortalDB offers resilience through redundancy, but requires careful handling of sensitive data and serialization. Devco can help you integrate it safely into your web application and evaluate trade-offs with alternatives.