Why I’m leaving Firebase for PouchDB… Or am I?
Wait, you’re both right!
TL;DR: I’ll be using both.
(I use PouchDB, Pouch, CouchDB, and Couch pretty interchangeably in this post. PouchDB is just a CouchDB wrapper that makes access from JS much easier. It also adds the ability to replicate data into client-side storage.)
I previously made a post citing the pros and cons of Firebase. Since then, I’ve completed my first non-trivial app with Firebase. I now feel I have a much deeper understanding of the challenges one faces when dealing with NoSQL solutions in general and Firebase in particular.
A lot of the criticisms I’ve heard about Firebase can be said about any NoSQL data store. There are security difficulties, data can be easily destroyed from the console, and there are no queries; as a few examples.
The queries issue is the big one. And to be fair, most NoSQL data stores have found clever solutions to that problem. In my previous article, I explained why querying a massive data store is so difficult. Firebase currently doesn’t have a good solution for retrieving data.
I started work on a solution to make Firebase more manageable. I created a tool to simplify and streamline CRUD. When I created it, I also started plans for ways to link data, query data, and keep de-normalized data from stagnating. After I finished the app I was working on, I was ramping up to getting started on that suite of tools.
Then one night during an insomnia fueled haze I realized it would probably be easier to learn something new than to build the suite of tools I had in mind for Firebase. I was up from 10PM to 5AM looking for an alternative. After 5 more hours of research the next day I finally settled on PouchDB. The problem was that I couldn’t scratch the itch of replacing Firebase’s 2 killer features — 3-way data binding and realtime data. PouchDB isn’t a perfect solution, but it’s the closest thing out there. And in many ways it’s even better.
A 3-way on fire or a 4-way on the couch?
PouchDB automatically syncs between local data and your datastore. Your data store can be hosted anywhere like a Docker microservice, a Raspberry Pi, or (my preferred choice) Cloudant. PouchDB watches your datastore and keeps it in sync with your local data. Using local data is perfect for mobile and Pouch claims to work well with Cordova. Pouch also delivers callbacks and promises that you can use to update your Angular model data. Et Voila, you now have 4-way data binding. It’s one extra step of work than with Angularfire, but it’s a very easy step.
Realtime data. What is real anyway?
CouchDB announces updates every 10 seconds and can be configured to happen much more often. This, of course, puts more strain on the database but there are a number of settings and adjustments that can be made to bring this very close to realtime. Even without the tweaking, 10 seconds isn’t bad at all for most uses.
Comparing PouchDB to my Firebase Pros:
- ✅ JSON
- ✅ simple serialization of app state
- 🚫 3-way data binding via Angularfire
(You actually get 4–way data binding but have to create your own equivalent to Angularfire.) - ✅ minimal setup
- 🚫 easy access to data, files, auth, and more
(PouchDB doesn’t offer authentication.) - ✅ no server infrastructure needed to power apps with data
- ✅ massive storage size potential
- 🚫 real time
(Technically no, but pretty close.) - pretty much the most advanced hosted BaaS solution
This is a bit subjective. - ✅ highly secure
- ✅ serverless
- 🚫 hey, it’s Google!
hey, it’s Apache!
Comparing PouchDB to my Firebase Cons:
- not widely used or battle tested for Enterprises
(CouchBase is a very widely accepted enterprise solution.) - very limited querying and indexing
(Couch has always had map / reduce and introduced querying 3 months ago with their 2.0 release.) - no aggregation
(Couch is outstanding at aggregation with its views feature. Plus you can do some crazy stuff with map / reduce.) - no map reduce
(Couch has it.) - can’t query or list users or stored files
(Couch has no authentication solution. You can attach files directly to documents.)
Where does each solution shine?
Firebase:
- realtime data
- authentication
- mobile services
PouchDB:
- querying and aggregation
- enterprise grade
- customizable and flexible
Which one should I use?
BOTH! I was strongly leaning toward Pouch but kept getting pulled back to that delicious realtime data feature. Then one day, while sitting on the toilet, it hit me out of the blue. Just use both! This is such a simple solution but it’s contrary to half a century of database practice common sense.
Seriously though, they’re both just APIs. I had intended to keep using Firebase for authentication anyways. I already had separate services for handling auth and data. Why not add another for other data? I can even have one service communicate with the other and share data for strategic overlap.
Let’s say I’m building a social network for fans of instructional webcomics. I would build member information, posts, and friendship connections with PouchDB. I would build the chat and gamification elements (think live leaderboards and public level up announcements) with Firebase.
