Working with databases

PouchDB databases come in two flavors: local and remote.

To create a local database, you simply call new PouchDB and give it a name:

var db = new PouchDB('kittens');

You can see a live example of this code.

Protip: whenever you see a live example in this guide, you can download it to follow along at home! For example, to run this example, just enter the following commands in your command prompt:

git clone kittens
cd kittens
python -m SimpleHTTPServer # for Python 2
python -m http.server # for Python 3

Now the site is up and running at http://localhost:8000. To find the correct URL, just click the "block" number at the top of the page.

To create a remote database, you call new PouchDB and give it a path to a database in CouchDB.

var db = new PouchDB('http://localhost:5984/kittens');
note: The remote database will not be created until you do an API call, e.g.: The reason behind that is that the PouchDB constructor is completely synchronous, for ease of error handling (i.e. no asynchronous errors).

The structure of a CouchDB URL is very simple:

http://     localhost:5984     /kittens
⌞_____⌟     ⌞____________⌟      ⌞_____⌟
   |              |                |
Protocol     Where CouchDB       database
(https if    itself is           name
Cloudant)    hosted

If the remote database doesn't exist, then PouchDB will create it for you.

You can verify that your database is working by visiting the URL http://localhost:5984/kittens. You should see something like this:


If instead you see:


Then check to make sure that your remote CouchDB has started up correctly. Common errors (such as CORS) are listed here.

You can see basic information about the database by using the info() method. (info) {

The local database should show something like:


The remote database may have a bit more information:


The most important bits of information are:

  • doc_count: the number of undeleted documents in the database
  • db_name: the name of the database

When you create a PouchDB database, there are many ways to debug and inspect it.

PouchDB Inspector

PouchDB Inspector is an add-on for Chrome that allows you to inspect your local databases.

PouchDB Inspector in Chrome

It provides the full "Fauxton" interface, which is the same interface you will see in CouchDB and PouchDB Server.

IndexedDB/WebSQL inspectors

You can also use the normal developer tools to see what your database looks like under the hood.

In Chrome, just choose Overflow icon ☰ → ToolsDeveloper Tools. Then click the Resources tab, then IndexedDB, and you should see the following:

Chrome Developer Tools

This is the raw IndexedDB representation of your PouchDB, so it is very fine-grained compared to what PouchDB Inspector shows. However, you may find it useful.

In Safari, your database will be under DevelopShow Web InspectorResourcesDatabases.

Web Inspector in Safari

Debug logging

You can also enable debug logging by doing:


And then disable it by doing:


During development, it's often useful to destroy the local database, so you can see what your users will experience when they visit your site for the first time. A page refresh is not enough, because the data will still be there!

In Chrome, you can use the ClearBrowserData extension, which will add a trashcan icon to your toolbar, which you can click to delete all local data (IndexedDB, WebSQL, LocalStorage, cookies, etc.).

In Firefox, you can use the Clear Recent History+ add-on, so when you right-click a page you can quickly clear all data.

In Safari, you can simply click SafariClear History and Website Data.

When you create a local PouchDB database, it uses whatever underlying datastore is available - IndexedDB in most browsers, WebSQL in older browsers, and LevelDB in Node.js.

When you create a remote PouchDB database, it communicates directly with the remote database – CouchDB, Cloudant, Couchbase, etc.

The goal of PouchDB is to allow you to seamlessly communicate with one or the other. You should not notice many differences between the two, except that of course the local one is much faster!

Now that you've created some databases, let's put some documents in 'em!