Choosing the Right Local Storage and Embedded Database for JavaScript Applications
This comparison evaluates six distinct approaches to local data persistence in JavaScript: levelup (a wrapper for the high-performance LevelDB), localforage (an asynchronous wrapper for browser storage APIs), lowdb (a simple JSON file database), nedb (an embedded MongoDB-like engine), node-persist (a synchronous JSON store for Node.js), and pouchdb (a browser-syncable NoSQL database). While all solve the problem of storing data locally, they differ fundamentally in their storage engines, synchronization capabilities, API styles (sync vs. async), and target environments (Node.js vs. Browser vs. Both).
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Embedded Databases in JavaScript: Architecture, Sync, and Performance Compared
When building JavaScript applications, knowing where and how to store data locally is a critical architectural decision. The ecosystem offers tools ranging from simple JSON file writers to full-blown NoSQL engines with sync capabilities. Let's break down how levelup, localforage, lowdb, nedb, node-persist, and pouchdb handle storage, querying, and environment compatibility.
⚠️ Critical Maintenance Status: A Warning on nedb
Before diving into features, we must address nedb. This package is deprecated and no longer maintained. Its repository has been archived, and it contains known security vulnerabilities that will not be fixed.
// ❌ DO NOT USE IN NEW PROJECTS
// const Nedb = require('nedb');
// This pattern is obsolete and unsafe.
If you need an embedded document store with a MongoDB-like API, you should migrate to pouchdb (for browser/Node sync) or consider modern alternatives like better-sqlite3 for relational needs. The rest of this comparison focuses on actively maintained solutions.
🗄️ Storage Engine: Key-Value vs. Document vs. JSON File
The fundamental difference lies in how data is structured and stored on disk or in the browser.
levelup provides a raw key-value store backed by LevelDB (or LMDB). It stores data as sorted strings or buffers. You manage serialization yourself.
// levelup: Raw key-value storage
const level = require('levelup');
const db = await level('./my-db');
// You must stringify objects manually
await db.put('user:1', JSON.stringify({ name: 'Alice', age: 30 }));
const data = await db.get('user:1');
const user = JSON.parse(data); // Manual parsing required
localforage abstracts browser storage (IndexedDB, WebSQL, localStorage) into a simple key-value API. It handles serialization automatically.
// localforage: Browser key-value with auto-serialization
import localforage from 'localforage';
// Automatically serializes the object
await localforage.setItem('user:1', { name: 'Alice', age: 30 });
const user = await localforage.getItem('user:1'); // Returns object directly
lowdb stores the entire database as a single plain JSON file on the filesystem. It loads the whole file into memory on every read.
// lowdb: Single JSON file storage
import { Low } from 'lowdb';
import { JSONFile } from 'lowdb/node';
const db = new Low(new JSONFile('db.json'), { users: [] });
await db.read();
// Direct mutation of the in-memory object
db.data.users.push({ name: 'Alice', age: 30 });
await db.write(); // Writes the entire JSON file back to disk
node-persist also uses a JSON file per key (or a single directory of files) but operates synchronously by default, blocking the Node.js event loop.
// node-persist: Synchronous file-based storage
const storage = require('node-persist');
await storage.init({ dir: 'data' });
// Synchronous write (blocks event loop)
storage.setItemSync('user:1', { name: 'Alice', age: 30 });
const user = storage.getItemSync('user:1');
pouchdb is a document-oriented database. It stores JSON documents with unique IDs and maintains internal indexes (B-trees) for efficient querying.
// pouchdb: Document store with internal indexing
import PouchDB from 'pouchdb';
const db = new PouchDB('my_database');
// Documents must have an _id
await db.put({ _id: 'user:1', name: 'Alice', age: 30 });
const doc = await db.get('user:1'); // Returns full document object
🔍 Querying Capabilities: Simple Lookups vs. Complex Filters
How you retrieve data varies wildly between these tools.
levelup, localforage, and node-persist are primarily key-value stores. They excel at fetching data by a specific key but lack built-in query engines for filtering by value.
// levelup: Stream keys to find matches (Manual filtering)
const stream = db.createKeyStream({ gte: 'user:', lte: 'user:\uffff' });
stream.on('data', (key) => {
// You must fetch and parse each value to check properties
});
// localforage: No native query support
// You must fetch all keys and iterate
const keys = await localforage.keys();
// Manual loop required to find specific users
lowdb relies on Lodash for querying the in-memory array. It is flexible but requires loading all data first.
// lowdb: Query via Lodash chain
import { Low } from 'lowdb';
// ... setup db ...
// Find users over 25
const adults = db.data.users.filter(u => u.age > 25);
pouchdb includes a powerful built-in query system (MapReduce or Mango indexes) that runs efficiently without loading all data into memory.
// pouchdb: Create an index
await db.createIndex({
index: { fields: ['age'] }
});
// Efficient query using the index
const result = await db.find({
selector: { age: { $gt: 25 } }
});
🔄 Synchronization: Offline-First vs. Local-Only
This is the biggest differentiator for modern web apps.
pouchdb is unique in this list because it supports bidirectional replication with CouchDB. This allows true "offline-first" architectures.
// pouchdb: Two-way sync with remote server
const remoteDB = new PouchDB('https://my-server.com/db');
const localDB = new PouchDB('local_db');
// Syncs changes automatically in both directions
localDB.sync(remoteDB, {
live: true,
retry: true
});
levelup, localforage, lowdb, and node-persist are strictly local. If you need sync, you must build the logic yourself (e.g., sending API requests on reconnect).
// localforage: Manual sync implementation required
async function syncData() {
const localData = await localforage.getItem('cache');
// You must write custom fetch/put logic to send to server
await fetch('/api/sync', { method: 'POST', body: JSON.stringify(localData) });
}
⚡ Performance and Concurrency Models
The way these libraries handle I/O impacts application responsiveness.
node-persist is synchronous. While simple, it blocks the Node.js event loop during disk operations, which can freeze your server under load.
// node-persist: Blocking operation
// The server cannot handle other requests during this write
storage.setItemSync('large-key', hugeDataObject);
levelup, localforage, lowdb (v2+), and pouchdb are asynchronous. They use Promises or callbacks to avoid blocking.
// levelup: Non-blocking async write
await db.put('key', 'value');
// Event loop remains free to handle other requests
// lowdb: Async write (v2+)
await db.write();
levelup generally offers the highest raw throughput for write-heavy workloads due to its Log-Structured Merge-tree (LSM) architecture, making it suitable for high-performance Node.js backends.
localforage is optimized for the browser, automatically choosing the fastest available backend (usually IndexedDB) while providing a consistent API.
🌐 Environment Compatibility
Where can you run these?
- Node.js Only:
levelup,lowdb,node-persist,nedb(deprecated). - Browser Only:
localforage(though it has a Node shim, it's designed for browsers). - Universal (Node + Browser):
pouchdb.
// pouchdb: Same code runs in Node and Browser
import PouchDB from 'pouchdb';
// Works in Chrome, Firefox, Safari, and Node.js
const db = new PouchDB('my_data');
📊 Summary: Key Differences
| Feature | levelup | localforage | lowdb | node-persist | pouchdb |
|---|---|---|---|---|---|
| Data Model | Key-Value | Key-Value | JSON File | Key-Value | Document (NoSQL) |
| Query Engine | None (Manual) | None (Manual) | Lodash (In-memory) | None (Manual) | MapReduce / Mango |
| Sync Ready | ❌ No | ❌ No | ❌ No | ❌ No | ✅ Yes (CouchDB) |
| I/O Model | Async | Async | Async | Sync (Blocking) | Async |
| Environment | Node | Browser | Node | Node | Universal |
| Best For | High perf, custom engines | Simple browser cache | CLI tools, prototypes | Simple Node scripts | Offline-first apps |
💡 The Big Picture
Choosing the right tool depends entirely on your constraints:
-
Building an Offline-First Web App? There is only one choice:
pouchdb. Its ability to sync with CouchDB saves months of custom engineering. The trade-off is bundle size and complexity. -
Need a Simple Cache in the Browser? Use
localforage. It gives you a clean Promise API without forcing you to deal with the quirks of IndexedDB directly. -
Writing a CLI Tool or Small Node Script?
lowdbis fantastic. Storing state as a human-readable JSON file makes debugging trivial. Just ensure your data set stays small. -
Building a High-Performance Node Backend?
levelupprovides the raw speed and durability of LevelDB. It requires more code to manage schemas and queries, but it scales incredibly well. -
Avoid at All Costs:
nedbis dead.node-persistshould be avoided for any server handling concurrent requests due to its blocking nature.
By matching the tool to your specific data access patterns and environment, you can avoid over-engineering while ensuring your application remains robust and maintainable.
How to Choose: levelup vs localforage vs lowdb vs nedb vs node-persist vs pouchdb
- levelup:
Choose
levelupwhen you need maximum performance and fine-grained control over key-value storage in a Node.js environment. It is ideal for building custom database layers, caching systems, or handling large datasets where direct access to the underlying LevelDB/LMDB engine is required. Avoid this if you need a ready-made query language or browser support without significant extra tooling. - localforage:
Choose
localforageif you are building a web application that needs a simple, asynchronous key-value store in the browser without worrying about the underlying implementation (IndexedDB, WebSQL, or localStorage). It is perfect for caching user preferences, offline data, or session state where you want a clean Promise-based API. Do not use this for complex queries or if you need data to sync with a remote server automatically. - lowdb:
Choose
lowdbfor small-scale Node.js projects, CLI tools, or prototypes where you need a tiny, full-featured database stored as a plain JSON file. It is excellent when you want to easily inspect and edit data manually and don't expect high concurrency or massive write volumes. Avoid it for production web servers with heavy traffic due to its synchronous file locking limitations. - nedb:
Do NOT choose
nedbfor new projects. It is officially deprecated and no longer maintained. While it offers a familiar MongoDB-like API for embedded use, critical security vulnerabilities and lack of updates make it unsafe. Instead, evaluatepouchdbfor similar query capabilities orlowdbfor simple JSON storage. - node-persist:
Choose
node-persistwhen you need an extremely simple, synchronous key-value store for Node.js scripts where performance is not critical and data is small. It is useful for caching build artifacts or storing simple configuration states in CLI tools. Avoid it for web servers or applications requiring asynchronous non-blocking I/O, as it blocks the event loop during read/write operations. - pouchdb:
Choose
pouchdbif your application requires offline-first capabilities with automatic bidirectional synchronization to a CouchDB server. It is the definitive choice for progressive web apps (PWAs) or mobile hybrids that must work seamlessly without internet and sync changes when connectivity returns. Be aware that it adds significant bundle size and complexity if you do not need the sync feature.
Popular Comparisons
README for levelup
levelup
Table of Contents
Click to expand
- Introduction
- Supported Platforms
- Usage
- API
levelup(db[, options[, callback]])db.supportsdb.open([options][, callback])db.close([callback])db.put(key, value[, options][, callback])db.get(key[, options][, callback])db.getMany(keys[, options][, callback])db.del(key[, options][, callback])db.batch(array[, options][, callback])(array form)db.batch()(chained form)db.statusdb.isOperational()db.createReadStream([options])db.createKeyStream([options])db.createValueStream([options])db.iterator([options])db.clear([options][, callback])
- What happened to
db.createWriteStream? - Promise Support
- Events
- Multi-process Access
- Contributing
- Big Thanks
- Donate
- License
Introduction
Fast and simple storage. A Node.js wrapper for abstract-leveldown compliant stores, which follow the characteristics of LevelDB.
LevelDB is a simple key-value store built by Google. It's used in Google Chrome and many other products. LevelDB supports arbitrary byte arrays as both keys and values, singular get, put and delete operations, batched put and delete, bi-directional iterators and simple compression using the very fast Snappy algorithm.
LevelDB stores entries sorted lexicographically by keys. This makes the streaming interface of levelup - which exposes LevelDB iterators as Readable Streams - a very powerful query mechanism.
The most common store is leveldown which provides a pure C++ binding to LevelDB. Many alternative stores are available such as level.js in the browser or memdown for an in-memory store. They typically support strings and Buffers for both keys and values. For a richer set of data types you can wrap the store with encoding-down.
The level package is the recommended way to get started. It conveniently bundles levelup, leveldown and encoding-down. Its main export is levelup - i.e. you can do var db = require('level').
Supported Platforms
We aim to support Active LTS and Current Node.js releases as well as browsers. For support of the underlying store, please see the respective documentation.
Usage
If you are upgrading: please see UPGRADING.md.
First you need to install levelup! No stores are included so you must also install leveldown (for example).
$ npm install levelup leveldown
All operations are asynchronous. If you do not provide a callback, a Promise is returned.
var levelup = require('levelup')
var leveldown = require('leveldown')
// 1) Create our store
var db = levelup(leveldown('./mydb'))
// 2) Put a key & value
db.put('name', 'levelup', function (err) {
if (err) return console.log('Ooops!', err) // some kind of I/O error
// 3) Fetch by key
db.get('name', function (err, value) {
if (err) return console.log('Ooops!', err) // likely the key was not found
// Ta da!
console.log('name=' + value)
})
})
API
levelup(db[, options[, callback]])
The main entry point for creating a new levelup instance.
dbmust be anabstract-leveldowncompliant store.optionsis passed on to the underlying store when opened and is specific to the type of store being used
Calling levelup(db) will also open the underlying store. This is an asynchronous operation which will trigger your callback if you provide one. The callback should take the form function (err, db) {} where db is the levelup instance. If you don't provide a callback, any read & write operations are simply queued internally until the store is fully opened, unless it fails to open, in which case an error event will be emitted.
This leads to two alternative ways of managing a levelup instance:
levelup(leveldown(location), options, function (err, db) {
if (err) throw err
db.get('foo', function (err, value) {
if (err) return console.log('foo does not exist')
console.log('got foo =', value)
})
})
Versus the equivalent:
// Will throw if an error occurs
var db = levelup(leveldown(location), options)
db.get('foo', function (err, value) {
if (err) return console.log('foo does not exist')
console.log('got foo =', value)
})
db.supports
A read-only manifest. Might be used like so:
if (!db.supports.permanence) {
throw new Error('Persistent storage is required')
}
if (db.supports.bufferKeys && db.supports.promises) {
await db.put(Buffer.from('key'), 'value')
}
db.open([options][, callback])
Opens the underlying store. In general you shouldn't need to call this method directly as it's automatically called by levelup(). However, it is possible to reopen the store after it has been closed with close().
If no callback is passed, a promise is returned.
db.close([callback])
close() closes the underlying store. The callback will receive any error encountered during closing as the first argument.
You should always clean up your levelup instance by calling close() when you no longer need it to free up resources. A store cannot be opened by multiple instances of levelup simultaneously.
If no callback is passed, a promise is returned.
db.put(key, value[, options][, callback])
put() is the primary method for inserting data into the store. Both key and value can be of any type as far as levelup is concerned.
options is passed on to the underlying store.
If no callback is passed, a promise is returned.
db.get(key[, options][, callback])
Get a value from the store by key. The key can be of any type. If it doesn't exist in the store then the callback or promise will receive an error. A not-found err object will be of type 'NotFoundError' so you can err.type == 'NotFoundError' or you can perform a truthy test on the property err.notFound.
db.get('foo', function (err, value) {
if (err) {
if (err.notFound) {
// handle a 'NotFoundError' here
return
}
// I/O or other error, pass it up the callback chain
return callback(err)
}
// .. handle `value` here
})
The optional options object is passed on to the underlying store.
If no callback is passed, a promise is returned.
db.getMany(keys[, options][, callback])
Get multiple values from the store by an array of keys. The optional options object is passed on to the underlying store.
The callback function will be called with an Error if the operation failed for any reason. If successful the first argument will be null and the second argument will be an array of values with the same order as keys. If a key was not found, the relevant value will be undefined.
If no callback is provided, a promise is returned.
db.del(key[, options][, callback])
del() is the primary method for removing data from the store.
db.del('foo', function (err) {
if (err)
// handle I/O or other error
});
options is passed on to the underlying store.
If no callback is passed, a promise is returned.
db.batch(array[, options][, callback]) (array form)
batch() can be used for very fast bulk-write operations (both put and delete). The array argument should contain a list of operations to be executed sequentially, although as a whole they are performed as an atomic operation inside the underlying store.
Each operation is contained in an object having the following properties: type, key, value, where the type is either 'put' or 'del'. In the case of 'del' the value property is ignored. Any entries with a key of null or undefined will cause an error to be returned on the callback and any type: 'put' entry with a value of null or undefined will return an error.
const ops = [
{ type: 'del', key: 'father' },
{ type: 'put', key: 'name', value: 'Yuri Irsenovich Kim' },
{ type: 'put', key: 'dob', value: '16 February 1941' },
{ type: 'put', key: 'spouse', value: 'Kim Young-sook' },
{ type: 'put', key: 'occupation', value: 'Clown' }
]
db.batch(ops, function (err) {
if (err) return console.log('Ooops!', err)
console.log('Great success dear leader!')
})
options is passed on to the underlying store.
If no callback is passed, a promise is returned.
db.batch() (chained form)
batch(), when called with no arguments will return a Batch object which can be used to build, and eventually commit, an atomic batch operation. Depending on how it's used, it is possible to obtain greater performance when using the chained form of batch() over the array form.
db.batch()
.del('father')
.put('name', 'Yuri Irsenovich Kim')
.put('dob', '16 February 1941')
.put('spouse', 'Kim Young-sook')
.put('occupation', 'Clown')
.write(function () { console.log('Done!') })
batch.put(key, value[, options])
Queue a put operation on the current batch, not committed until a write() is called on the batch. The options argument, if provided, must be an object and is passed on to the underlying store.
This method may throw a WriteError if there is a problem with your put (such as the value being null or undefined).
batch.del(key[, options])
Queue a del operation on the current batch, not committed until a write() is called on the batch. The options argument, if provided, must be an object and is passed on to the underlying store.
This method may throw a WriteError if there is a problem with your delete.
batch.clear()
Clear all queued operations on the current batch, any previous operations will be discarded.
batch.length
The number of queued operations on the current batch.
batch.write([options][, callback])
Commit the queued operations for this batch. All operations not cleared will be written to the underlying store atomically, that is, they will either all succeed or fail with no partial commits.
The optional options object is passed to the .write() operation of the underlying batch object.
If no callback is passed, a promise is returned.
db.status
A readonly string that is one of:
new- newly created, not opened or closedopening- waiting for the underlying store to be openedopen- successfully opened the store, available for useclosing- waiting for the store to be closedclosed- store has been successfully closed.
db.isOperational()
Returns true if the store accepts operations, which in the case of levelup means that status is either opening or open, because it opens itself and queues up operations until opened.
db.createReadStream([options])
Returns a Readable Stream of key-value pairs. A pair is an object with key and value properties. By default it will stream all entries in the underlying store from start to end. Use the options described below to control the range, direction and results.
db.createReadStream()
.on('data', function (data) {
console.log(data.key, '=', data.value)
})
.on('error', function (err) {
console.log('Oh my!', err)
})
.on('close', function () {
console.log('Stream closed')
})
.on('end', function () {
console.log('Stream ended')
})
You can supply an options object as the first parameter to createReadStream() with the following properties:
-
gt(greater than),gte(greater than or equal) define the lower bound of the range to be streamed. Only entries where the key is greater than (or equal to) this option will be included in the range. Whenreverse=truethe order will be reversed, but the entries streamed will be the same. -
lt(less than),lte(less than or equal) define the higher bound of the range to be streamed. Only entries where the key is less than (or equal to) this option will be included in the range. Whenreverse=truethe order will be reversed, but the entries streamed will be the same. -
reverse(boolean, default:false): stream entries in reverse order. Beware that due to the way that stores like LevelDB work, a reverse seek can be slower than a forward seek. -
limit(number, default:-1): limit the number of entries collected by this stream. This number represents a maximum number of entries and may not be reached if you get to the end of the range first. A value of-1means there is no limit. Whenreverse=truethe entries with the highest keys will be returned instead of the lowest keys. -
keys(boolean, default:true): whether the results should contain keys. If set totrueandvaluesset tofalsethen results will simply be keys, rather than objects with akeyproperty. Used internally by thecreateKeyStream()method. -
values(boolean, default:true): whether the results should contain values. If set totrueandkeysset tofalsethen results will simply be values, rather than objects with avalueproperty. Used internally by thecreateValueStream()method.
db.createKeyStream([options])
Returns a Readable Stream of keys rather than key-value pairs. Use the same options as described for createReadStream() to control the range and direction.
You can also obtain this stream by passing an options object to createReadStream() with keys set to true and values set to false. The result is equivalent; both streams operate in object mode.
db.createKeyStream()
.on('data', function (data) {
console.log('key=', data)
})
// same as:
db.createReadStream({ keys: true, values: false })
.on('data', function (data) {
console.log('key=', data)
})
db.createValueStream([options])
Returns a Readable Stream of values rather than key-value pairs. Use the same options as described for createReadStream() to control the range and direction.
You can also obtain this stream by passing an options object to createReadStream() with values set to true and keys set to false. The result is equivalent; both streams operate in object mode.
db.createValueStream()
.on('data', function (data) {
console.log('value=', data)
})
// same as:
db.createReadStream({ keys: false, values: true })
.on('data', function (data) {
console.log('value=', data)
})
db.iterator([options])
Returns an abstract-leveldown iterator, which is what powers the readable streams above. Options are the same as the range options of createReadStream() and are passed to the underlying store.
These iterators support for await...of:
for await (const [key, value] of db.iterator()) {
console.log(value)
}
db.clear([options][, callback])
Delete all entries or a range. Not guaranteed to be atomic. Accepts the following range options (with the same rules as on iterators):
gt(greater than),gte(greater than or equal) define the lower bound of the range to be deleted. Only entries where the key is greater than (or equal to) this option will be included in the range. Whenreverse=truethe order will be reversed, but the entries deleted will be the same.lt(less than),lte(less than or equal) define the higher bound of the range to be deleted. Only entries where the key is less than (or equal to) this option will be included in the range. Whenreverse=truethe order will be reversed, but the entries deleted will be the same.reverse(boolean, default:false): delete entries in reverse order. Only effective in combination withlimit, to remove the last N records.limit(number, default:-1): limit the number of entries to be deleted. This number represents a maximum number of entries and may not be reached if you get to the end of the range first. A value of-1means there is no limit. Whenreverse=truethe entries with the highest keys will be deleted instead of the lowest keys.
If no options are provided, all entries will be deleted. The callback function will be called with no arguments if the operation was successful or with an WriteError if it failed for any reason.
If no callback is passed, a promise is returned.
What happened to db.createWriteStream?
db.createWriteStream() has been removed in order to provide a smaller and more maintainable core. It primarily existed to create symmetry with db.createReadStream() but through much discussion, removing it was the best course of action.
The main driver for this was performance. While db.createReadStream() performs well under most use cases, db.createWriteStream() was highly dependent on the application keys and values. Thus we can't provide a standard implementation and encourage more write-stream implementations to be created to solve the broad spectrum of use cases.
Check out the implementations that the community has produced here.
Promise Support
Each function accepting a callback returns a promise if the callback is omitted. The only exception is the levelup constructor itself, which if no callback is passed will lazily open the underlying store in the background.
Example:
const db = levelup(leveldown('./my-db'))
await db.put('foo', 'bar')
console.log(await db.get('foo'))
Events
levelup is an EventEmitter and emits the following events.
| Event | Description | Arguments |
|---|---|---|
put | Key has been updated | key, value (any) |
del | Key has been deleted | key (any) |
batch | Batch has executed | operations (array) |
clear | Entries were deleted | options (object) |
opening | Underlying store is opening | - |
open | Store has opened | - |
ready | Alias of open | - |
closing | Store is closing | - |
closed | Store has closed. | - |
error | An error occurred | error (Error) |
For example you can do:
db.on('put', function (key, value) {
console.log('inserted', { key, value })
})
Multi-process Access
Stores like LevelDB are thread-safe but they are not suitable for accessing with multiple processes. You should only ever have a store open from a single Node.js process. Node.js clusters are made up of multiple processes so a levelup instance cannot be shared between them either.
See Level/awesome for modules like multileveldown that may help if you require a single store to be shared across processes.
Contributing
Level/levelup is an OPEN Open Source Project. This means that:
Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit. This project is more like an open wiki than a standard guarded open source project.
See the Contribution Guide for more details.
Big Thanks
Cross-browser Testing Platform and Open Source ♥ Provided by Sauce Labs.
Donate
Support us with a monthly donation on Open Collective and help us continue our work.