levelup vs localforage vs lowdb vs nedb vs node-persist vs pouchdb
JavaScript Data Storage Libraries
leveluplocalforagelowdbnedbnode-persistpouchdbSimilar Packages:

JavaScript Data Storage Libraries

These libraries provide various solutions for data storage in JavaScript applications, catering to different needs such as local storage, persistence, and synchronization. They enable developers to manage data efficiently, whether in a server-side Node.js environment or client-side web applications. Each library has unique features and use cases, making it essential to choose the right one based on the specific requirements of your project.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
levelup04,079-04 years agoMIT
localforage025,775-2495 years agoApache-2.0
lowdb022,47422.9 kB152 years agoMIT
nedb013,564-20810 years agoSEE LICENSE IN LICENSE
node-persist072840.1 kB17a year agoMIT
pouchdb017,5525.53 MB1592 years agoApache-2.0

Feature Comparison: levelup vs localforage vs lowdb vs nedb vs node-persist vs pouchdb

Storage Type

  • levelup:

    LevelUP is a wrapper around LevelDB, providing a key-value store that is fast and efficient for large datasets. It is designed for server-side applications, allowing for complex data structures and high performance.

  • localforage:

    LocalForage abstracts different storage mechanisms like IndexedDB, WebSQL, and localStorage, allowing developers to use a simple API for asynchronous storage. It is primarily used for client-side applications needing offline capabilities.

  • lowdb:

    LowDB is a simple JSON database that stores data in a JSON file, making it easy to read and write. It is suitable for small projects and prototyping, where a lightweight solution is needed without complex setup.

  • nedb:

    NeDB is an embedded database that provides a MongoDB-like API for Node.js applications. It stores data in a file and supports indexing, making it suitable for applications that need a lightweight database with querying capabilities.

  • node-persist:

    Node-Persist is a key-value store that saves data to the file system, providing a simple way to persist data in Node.js applications. It is ideal for applications that require basic data storage without complex features.

  • pouchdb:

    PouchDB is a NoSQL database that can sync with CouchDB, allowing for offline data storage and synchronization across devices. It is designed for web and mobile applications that require robust data handling and offline capabilities.

Ease of Use

  • levelup:

    LevelUP has a straightforward API that allows developers to perform CRUD operations easily. However, it requires some understanding of LevelDB concepts to utilize its full potential effectively.

  • localforage:

    LocalForage offers a simple and intuitive API that makes it easy for developers to store and retrieve data asynchronously, making it a great choice for web applications.

  • lowdb:

    LowDB is extremely easy to set up and use, with a minimalistic API that allows developers to read and write data in JSON format without much overhead.

  • nedb:

    NeDB provides a familiar MongoDB-like API, making it easy for developers who are already accustomed to MongoDB to use it without a steep learning curve.

  • node-persist:

    Node-Persist has a simple API for storing and retrieving key-value pairs, making it easy for developers to implement persistent storage in their applications.

  • pouchdb:

    PouchDB has a user-friendly API that simplifies data synchronization and offline storage, making it accessible for developers to implement complex features without much hassle.

Performance

  • levelup:

    LevelUP is optimized for performance, especially with large datasets, as it leverages LevelDB's efficient storage and retrieval mechanisms, making it suitable for high-performance applications.

  • localforage:

    LocalForage provides good performance for client-side storage, but its speed can vary depending on the underlying storage mechanism used by the browser.

  • lowdb:

    LowDB is not designed for high-performance applications, as it reads and writes data to a JSON file, which can become a bottleneck with larger datasets.

  • nedb:

    NeDB offers decent performance for small to medium-sized datasets, but it may struggle with very large datasets due to its file-based storage approach.

  • node-persist:

    Node-Persist is suitable for small-scale applications, but performance may degrade with larger datasets due to file system I/O operations.

  • pouchdb:

    PouchDB is designed for performance and can handle large datasets efficiently, especially with its ability to sync data with CouchDB.

Data Synchronization

  • levelup:

    LevelUP does not provide built-in data synchronization features, as it is primarily focused on local storage and retrieval.

  • localforage:

    LocalForage does not support data synchronization out of the box, but it can be used in conjunction with other libraries to achieve this functionality.

  • lowdb:

    LowDB does not offer data synchronization features, as it is intended for simple, local data storage without complex requirements.

  • nedb:

    NeDB does not natively support data synchronization, but it can be used in applications where data consistency is managed manually.

  • node-persist:

    Node-Persist does not provide synchronization capabilities, focusing instead on simple key-value storage.

  • pouchdb:

    PouchDB excels in data synchronization, allowing seamless syncing with CouchDB and other PouchDB instances, making it ideal for applications that require offline capabilities and data consistency across devices.

Use Cases

  • levelup:

    LevelUP is best suited for applications that require a fast and efficient key-value store, such as caching, session storage, or managing large datasets in Node.js environments.

  • localforage:

    LocalForage is ideal for web applications that need to store user data offline, such as progressive web apps (PWAs) that require persistent storage across sessions.

  • lowdb:

    LowDB is perfect for small projects, prototypes, or applications that need a simple, file-based database without the overhead of a full database system.

  • nedb:

    NeDB is suitable for desktop applications or small server-side applications that require a lightweight database with a familiar API for MongoDB users.

  • node-persist:

    Node-Persist is great for applications that need simple key-value storage, such as caching or storing user preferences in Node.js applications.

  • pouchdb:

    PouchDB is best for mobile and web applications that require robust offline capabilities and data synchronization across devices, making it ideal for collaborative applications.

How to Choose: levelup vs localforage vs lowdb vs nedb vs node-persist vs pouchdb

  • levelup:

    Choose LevelUP if you need a simple and flexible way to work with LevelDB, especially for applications that require a fast key-value store with a focus on performance and scalability. It's ideal for Node.js applications that need to handle large amounts of data efficiently.

  • localforage:

    Select LocalForage if you are looking for a library that provides a simple API for asynchronous storage, supporting multiple backends like IndexedDB, WebSQL, and localStorage. It's perfect for web applications that require offline capabilities and a consistent API across different browsers.

  • lowdb:

    Opt for LowDB if you need a lightweight JSON database for small projects or prototyping. It is easy to set up and use, making it suitable for applications that require simple data storage without the overhead of a full database system.

  • nedb:

    Use NeDB if you want a lightweight, embedded database for Node.js applications that resembles MongoDB's API. It is suitable for applications that require a simple, file-based database with indexing and querying capabilities without the need for a full-fledged database server.

  • node-persist:

    Choose Node-Persist if you need a simple and persistent key-value store for Node.js applications. It is easy to use and provides a straightforward way to store data on the file system, making it suitable for small-scale applications or caching.

  • pouchdb:

    Select PouchDB if you need a powerful database that can sync with CouchDB and work offline. It is ideal for applications that require data synchronization across devices and offline capabilities, making it suitable for mobile and web applications.

README for levelup

levelup

level badge npm Node version Test Coverage Standard Common Changelog Donate

Table of Contents

Click to expand

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.

Sauce Test Status

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.

  • db must be an abstract-leveldown compliant store.
  • options is 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 closed
  • opening - waiting for the underlying store to be opened
  • open - successfully opened the store, available for use
  • closing - waiting for the store to be closed
  • closed - 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. When reverse=true the 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. When reverse=true the 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 -1 means there is no limit. When reverse=true the 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 to true and values set to false then results will simply be keys, rather than objects with a key property. Used internally by the createKeyStream() method.

  • values (boolean, default: true): whether the results should contain values. If set to true and keys set to false then results will simply be values, rather than objects with a value property. Used internally by the createValueStream() 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. When reverse=true the 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. When reverse=true the 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 with limit, 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 -1 means there is no limit. When reverse=true the 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.

EventDescriptionArguments
putKey has been updatedkey, value (any)
delKey has been deletedkey (any)
batchBatch has executedoperations (array)
clearEntries were deletedoptions (object)
openingUnderlying store is opening-
openStore has opened-
readyAlias of open-
closingStore is closing-
closedStore has closed.-
errorAn error occurrederror (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.

Sauce Labs logo

Donate

Support us with a monthly donation on Open Collective and help us continue our work.

License

MIT