Support for CouchDB/Cloudant is meteor is now available on Atmosphere

Hello everyone,

For a few months now Praveen Devarao and me worked on integrating Meteor with Apache CouchDB. The package is released on Atmosphere few hours ago -

The code for a couple of sample apps is located here -

I think most folks will be aware that Apache CouchDB is an open source JSON data store. Apache Couch DB 2.0 has a query API that is similar like Mongo’s, contributed by Cloudant and been available on Cloudant DBaas for quite a while now.

The package simply reuses minimongo on the client side (more proof that the Query API’s are ‘same’ :smile: )

The readme of the package both on Atmosphere and in github, document how you can use the module and its API.

We would love to get your feedback and see what works well and what doesn’t. We do plan to maintain it and keep it up-to-date maybe build more features – your input can help shape the future of this package. Please feel to open any issues, feature request in the github repo



This is interesting. I tried to run this with cloudant and received the following at startup.

“Error: one of _design, _admin is required for this request”. I am using an api key and associated pass instead of root user and pass.

Just wanted to clarify a couple of things. The Database URL that is passed (in COUCHDB_URL - it ends with port - with no database name) is that of a cloudant instance - Does it need an actual database (Cloudant DB) to be mentioned? I was thinking maybe a “meteor” cloudant database would be created with the supplied credentials.

How are different collections mapped in Cloudant? As documents with different types in a single database or do they go into different databases?

Got it working with root user and password. Creates a new “database” for each collection. Thanks !

1 Like

@sathishc first off, thanks for giving the module a try and the feedback. Thank you.
To answer you questions

  1. The Database URL should not include a database name (should end with port)

  2. When you do a ‘new CouchDB.Database(dbname)’ , if the Database doesn’t exist there is an attempt to create it. If it already exists, there is an attempt to create/update some designDocs that this module needs. The former requires you to have permissions to create DB’s (_admin) and the latter requires you to have either of _design/_admin on the specific database.

Since APIKeys can only be given permissions tied to databases, here is the pattern as i see it - if you are using APIKeys, root should pre-create the databases you are going to use from meteor and ensure that the apiKey used from meteor has _admin permission on those databases, in addition to read/write permission on those databases (using the UI i havent seen a way to specify the _design perm for an apikey on the DB, so i am suggesting _admin). With this, one can use Apikeys with this module

I will add a note to the Readme about using apikeys with this module

  1. As you have already figured out, each CouchDB.Database() from meteor goes into its own DB.

Any chance of using for client side data caching/offline support? Could greatly speed up load times reduce load by controlling sync rates

hey not the first time asked and i am sure many more will. Started with that idea but took a turn as mentioned here - Apache CouchDB support released in Atmosphere

1 Like

We’re using this package in our data analysis pipeline at Chaser. Really impressed with it so far. Have blogged about our experience: Meteor + Python + Cloudant: a simple, scalable architecture for data analysis.

1 Like

Hey thanks for the kind words. I opened an issue for the read-only access hiccup you hit Please feel free to chime in there