+1 for the community. Everyone who's worked with Pouch/Couch seems to become an evangelist eventually, which speaks volumes for how well designed the platforms are (Flaws and all). People genuinely seem to enjoy working on them, and they solve real problems in very neat and interesting ways.

Did you also consider Couchbase Lite? I'd be interested in your decision making.

I've used pouch on a few projects and also attempted to use cb lite. I found pouch dramatically easier to get up and running with.

Cb lite was complicated since it needs a native plugin rather than being just js. That wasn't too bad.

The thing that put the nail in it for me was all the setup on the server side with sync gateways, multiple databases that then sync with one another, etc etc.

CBL has worked OK so far for us with just plain CouchDB serverside, no sync gateways. But I can see where you're coming from, if your stack is centered around JS I think pouchDB makes more sense. We have potentially large DBs (depends on usecase) where browser context isn't enough and/or provides a bad user experience.

Oh so you're using CBL with a couchdb backend? I didn't even realise that was possible. I thought it only synced with Couchbase which is where all the complexity came in.

Yes it's possible. Here and there there might be a quirk but so far nothing that set us back too much. I'm not a fan of Couchbase's Syncgateways either, I'm not sure the problem they're solving is a very common one.

sync_gateway is basically a couchdb protocol proxy, for couchbase-lite to use, that sits in front of couchbase.

couchbase-lite apparently also works with couchdb (protocol compliant) and cloudant.

I am currently working at a gig where the use of couchbase-lite with sync gateway and couchbase are required for a project.

Couchbase Lite was not something that we considered. Once we got PouchDB up and running it seemed to fit our needs well enough that we stopped considering alternatives.

I've upvoted davidbanham's comment because that seems like a more insightful answer to your question.

Thanks for responding! These kinds of discussions are exactly why I like HN so much.

I explored using Couchbase Lite in an app and realized that PouchDB was still the best client library for it, and at least in my testing of Couchbase Lite's Cordova plugin I saw a bunch of bugs (the Windows version of Couchbase Lite still isn't included in the Cordova plugin; the Cordova plugin is still called a PhoneGap plugin and seems to be lagging behind by several major Cordova versions last I tried to install it), and didn't see much in the way of a performance benefit on even iOS/Android over PouchDB's performance with IndexedDB and/or SQLite.

+1 for a great community with CBL, too! Whenever we've had some trouble or a question, we've had helpful, friendly advice. I'm a big fan of CouchDb, Pouch, and CBL, all of which my team uses. Note that we use CBL with our native mobile apps.

Is CBL able to sync with CouchDB 2.0? Couldn't tell from looking quickly at their website.

How many databases out there work with React Native? I think http://lokijs.org does with Forage, and (I work on) https://github.com/amark/gun people have been getting it to work with adapters. The comment below seems to suggest Couchbase Lite does too? What made you guys decide on Pouch for React Native apps?

Sorry, I haven't yet tried CBL together with react, so I don't know how mature that solution would be - CBL works with native ObjC/Java code, so I guess some adapters would be needed for React to work with it. This at the same time is one of my problems with React Native - it's expensive in programmer time to access resources / native libraries that aren't provided yet by the core. Just to compare with a very small project: python-for-android, there you can directly access any Java function available on the device runtime, it automatically binds to all of it. React native on the other hand seems very frameworky and boxed in, but has a great portable UI definitions and build/prototyping workflow.

I hope one day soon, after already 10 years of iPhone, we finally get a sane development environment again - with stable APIs, responsive UIs, portable code, easy networking and persistence, but at the same time fast to prototype and hook up. All the solutions I know are around 70%-80% there, there's always something that hurts badly.

Here's React Native Couchbase Lite docs https://github.com/couchbaselabs/react-native-couchbase-lite...

"not an official couchbase plugin and is not supported in any way by couchbase"

That's what I meant with cost.

Edit: Btw. thanks for the link.

It may not be supported but the wrote a blog post about it a while ago. "Our product can be used on RN! (but don't ask us for support.)"

Do you mind me asking why you choose to use PouchDB in this way instead of Realm for React Native?

Realm looks pretty cool. I'll consider using it in future projects. At the time of starting the project (April 2016), here are some thoughts:

1) Realm works only in React Native and not in React web. There is a regular web component to my project as well and the thought was we could reuse our knowledge of PouchDB across mobile and web. This has paid off in the prototype mode because it allowed us to build some simple reports in our web product. However, this is probably not the right architecture for reporting and we will likely change it soon.

2) Realm was very new and I felt we were already using too many new frameworks. So it was added risk on a tight timeline to get a prototype out the door.

3) On the server side, CouchDB has Futon to simplify our learning curve and give us a basic GUI to have a sanity check when our code wasn't functioning as expected. Not sure what Realm's server side looks like.

I'm sure I can come up with other reasons. But definitely want to check out Realm sometime. Looks like it is shaping up quite nicely.

Realm looks very promising, but the lack of a version that can run in the browser is also why I had to cross it off my list of potential DBs for the project I'm working on. Is a browser port on the roadmap by any chance?

Similar time-frame and platform. We opted to use Realm instead because it offers encrypted storage exposed to React-Native. Would have loved to use *ouchDB but this was a missing critical piece.

1. Realm on the server/sync is closed beta at the moment. It's not ready. 2. Realms design does not gel well if you use Redux architecture.

That's amazing. Did you open-source your react-native shim yet? I'd love to see it