What are the differences between CouchDB, Firebase, Parse, and PouchDb

I am a front end developer. However, I would like to learn backend development. I have been searching databases knowledge and have no idea which one to go for. Could you elaborate whart are the differences between CouchDB, Firebase, Parse, and PouchDb?


I haven’t used CouchDB or PouchDB in a mobile app, but my understanding is PouchDB still uses CouchDB on the backend, but allows for offline saving, and then it updates CouchDB once it detects a connection.

I’m using Parse now and I’ve used Firebase before, though not the extent I’m using Parse.

Parse and Firebase are both Backend as a Service (BAAS), which is basically a service you can use for saving data, such as user profiles, images, sessions and device information.

Wiki: https://en.wikipedia.org/wiki/Mobile_Backend_as_a_service

Since I’m using Parse extensively I will talk about that, but basically you can swap out Parse for Firebase with almost no issues.

In short, I’m really enjoying Parse. It made it incredibly fast to get started and give my app a backend and push notifications and I highly recommend it, but I’m planning on moving away from Parse as soon as I finish my app.

Heres how I’m using parse:

User signs up and I create a new user on parse.
User logs in and Parse creates a new session for that user.
User allows Push notifications and I register their device on Parse.
User sends Push notification, so using parse, I can send out their push notifications to other devices registered on Parse.

I also used Parse to save files, but since moved to AWS S3.

My experience with Parse has been great so far. It gives you incredibly easy user management, and handles authentication pretty well. I can basically flip a switch for when a user signs up and Parse will send an email for them to verify their email account. You can also do the same for password resets.

The limitation I am seeing is in the requests you are allowed a second. The free tier gives you 30/req/s, which should be pretty good for a lot of people, but I want to scale my app way past that. (Quick example on that, I was able to test 10,000 requests to parse over a few minutes, and never hit the free limit).

A work around for limiting requests is to also include another backend to reduce the requests to parse. Basically what I do is only use Parse for user signups/logins, sessions and push notifications. When I create a user account on Parse, I also create a new user document on Mongo. Anything else I save on MongoDB. So if a user wants to change their profile, I update a Mongo Doc instead of sending a request to Parse.

You might be asking why use parse in the first place? The reason is back to user management. I don’t have time right now to tinker with handling password encryption, password resets, verifing emails and I don’t want to set up a Push server when I can focus on making the app awesome.

I’m not including anything specific to Parse in my app, everything is on the server, so when I want to rip out Parse, I can do so without any app updates. And I don’t include any Parse credentials within my app.

I hope all that made sense, I started to go off a bit, so if you have any more questions, feel free to ask me. In short, Parse/Firebase = BAAS, and I would recommend them in the early stages of your app.
PouchDB = CouchDB with offline Sync. I would recommend those in addition to Parse/Firebase, to help reduce the load on Parse/Firebase.

I’ve also had really positive experiences with using MongoDB hosted on MongoLabs.

I’ll probably get crap for saying just pick on DB and run with it, since at their core not all DB languages are the same and you could spend hours and hours researching each little difference, but in the end, pick one that has good community support and you think will work with your app and go with it. So I say go with PouchDB. Don’t get caught up in constant research. Just build, learn and get experience.


As an extension you can use cordova sqlite plugin in combination with pouchdb :slight_smile:

1 Like

Hi DaDanny,

Really thanks for your great information.
It really helps.
I google about Parse vs Firebase. Many says that firebase have the real-time syncing capability. However, Parse does not. In that case if use Parse as BAAS. Is there a way to make parse do real time syncing work as well?


Also have a look at https://github.com/colinskow/superlogin. It uses CouchDB in the backend and PouchDB in the frontend and syncs when the device gets online (configurable). It ships with UserManagement and you can define per-User-Databases and shared databases. Playing the last two days with it and its fantastic so far.

1 Like

Hello Jaden, What did you end up going with. Did you look into price at all?

Here’s the latest for the Googlers:

Parse is dead and gone.


  • a CouchDB wrapper
  • open source
  • been around for 5 years.
  • automagically syncs offline and online data
  • just works


  • open source
  • been around for 12 years
  • generous free tier of hosting at Cloudant by IBM
  • uses map / reduce as well as queries
  • very advanced and configurable


  • proprietary
  • been around for 5 years
  • generous free tier of hosting by Google
  • offers realtime data
  • easy to use and set up
  • has almost no querying ability, no map / reduce, and limits relational workarounds

In summary, use PouchDB AND Firebase.
Use Firebase when all you care about is real time data - chat, games, locator apps.
Use PouchDB for pretty much everything else - structured data, scalability, queries.
They play nice with each other and can totally trade off abilities by setting up a service for each one in your app.

1 Like

Thanks for answering.

Yes, please feel inspired to write your own article/post of this subject. No one seems to have done that yet. I think many out there like me, has been asking the same question about how PouchDB fits in with Firebase and where it should been used and how. You would be the first is my strong feeling.

Curious: Why do you call it cold/hot data ?

Somewhere it feels that It need some kind of a proxy service pattern one part that handling the local part (for the database) in the client side and the other part is the (firebase) connection so it would be the remotedb (not the couchdb) even if pouchdb seems to fit naturally with the couchdb. Right ? (sry for the high level explanation :wink: )

Sorry to the author if this thread steeling a bit of the focus from what the main purpose was from beginning. Perhaps this is worth another post/blog to continue the discussion.

I have a system I call hot data / cold data. I set up Firebase in the usual way. Then I set up Pouch in the usual way. I have a provider for each one that handles the low level data access. Then I add a factory to generate an object that has basic CRUD functions from each one. They both have the same methods. So I can do:

hotData.create()  //create from stored hot data
coldData.create() //create from stored cold data

They both do the same thing but one goes to Firebase, the other to Couch.

I’m sorry for such a high level explanation. I’ll be doing a blog post on the subject very soon and post here when I do.

my blog on medium

Sorry for the slow response. There’s no update if you edit your post, only if you post anew.
I call it hot data cold data for 2 reasons.

  1. firebase - fire is hot and couch starts with c for cold
  2. firebase data is live and real time so it’s hot like a live high voltage cable.
    couchDB - is better for long term storage and retrieval like cold storage.

It seems like it may be a while for me to get around to this article.
I keep wanting to do more and more with it.
It’s become a small book in my mind.
I may just release a full pdf on it actually.
While it’s easy to overthink it, the core concept is dead simple.

So here it is in essence:

  • set up firebase in your app module in the usual way.
  • have a HotData provider that imports AngularFireDatabase
  • have a ColdData provider that imports PouchDb and connects it to your CouchDB (I use Cloudant)
  • write an interface with all your CRUD methods
  • make your HotData and ColdData providers implement the interface
  • add the CRUD methods to each one.

That’s really it. They work completely independently of each other.
If you want access to firebase for a chat room for example, run HotData.runQuery(query).
If you want to retrieve analytics data for example, run ColdData.runQuery(query).

So basically, figure out how to get Firebase up and running. Get good at it.
Figure out how to get PouchDB up and running. Get good at that.
Then you can use either one at any time in the same app.

If you want to share data between the 2, I recommend using a PubSub system.
I set one up with ReactJS Subjects.
But that’s a whole other topic unto itself.