NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



CouchApp: All content tagged as CouchApp in NoSQL databases and polyglot persistence

CouchDB as Email Store

If you ever get bored of your GMail/Yahoo!/Hotmail email or your local client, then you could start storing email into CouchDB. Next you could develop a CouchApp for it, add tags and views to emulate folders/GMail labels, replicate to your mobile or other machine, etc. The Reddit community hasn’t appreciated the idea though.

Original title and link: CouchDB as Email Store (NoSQL databases © myNoSQL)

node.js + CouchDB == Crazy Delicious

Mikeal Rogers (@mikeal) talking on why node.js and CouchDB are a good fit for each other:

Now, there’s already LivelyCouch which tries to build an application server by combining node.js and CouchDB. And there’s also CouchApp which allows you to build apps directly in CouchDB.

Original title and link: node.js + CouchDB == Crazy Delicious (NoSQL databases © myNoSQL)

Powered by CouchApp: MapChat

Nice little CouchApp: MapChat:

MapChat: CouchApp

Why CouchApp/CouchDB? I guess the answer in this case is: development simplicity, as there’s no need for additional web server or other things like that. Just CouchDB and a bunch of Javascript.

Original title and link: Powered by CouchApp: MapChat (NoSQL databases © myNoSQL)

RavenDB, Attachments, and Raven Apps

Looks like RavenDB took a lot of inspiration from CouchDB and CouchApp:

The only reason RavenDB has attachments support is that we wanted to support the notion of Raven Apps (see Couch Apps) which are completely hosted in RavenDB. That was the original impetus. Since then, they evolved quite nicely. Attachments in RavenDB can have metadata, are replicated between nodes, can be cascade deleted on document deletions and are HTTP cacheable.

I didn’t even know RavenDB has something like CouchApps RavenApps.

Original title and link: RavenDB, Attachments, and Raven Apps (NoSQL databases © myNoSQL)


CouchDB Usecase: Decentralizing Twitter

J.Chris Anderson in an interview over ReadWriteWeb:

Klint Finley: Let’s start at the top: what exactly is Twebz? It’s described as a “decentralized Twitter client.” What exactly does that mean?

J Chris Anderson: The aim is to allow you to interact with Twitter when Twitter is up and you are online. But if Twitter is down for maintenance or you are in the middle of nowhere, you can still tweet. And when you can reach Twitter again, it will go through.

If lots of folks are using it, then they can see each other’s tweets come in even when Twitter is down.

Mostly the goal was to show the way on how to integrate CouchDB with web services and APIs.

A classical example of CouchDB powerful P2P replication capabilities. Dave Winer would probably be its ☞ biggest fan.

Original title and link: CouchDB Usecase: Decentralizing Twitter (NoSQL databases © myNoSQL)


CouchApps Marketplace: A (Possible) Future for CouchDB

When I’ve heard the coherent CouchOne’s positioning, the very next thought was of a CouchApps marketplace. Looks like someone already got to it:

Our platform assumes all functionality be placed on top of conversations management framework in a form of CouchApps (well, with a few twists, but CouchApps it is in the bare-bone). We are busy building number of useful apps ourselves, but got to the point where our framework is stable enough to start inviting 3rd party developers to work alongside with us. The apps are expected to cover project management and social life needs of the team.

Essentially, the business model have pivoted to, is the freemium for the core framework, with the marketplace for additional apps. We would host all apps in our runtime wherever possible. The pricing would be subscription-based per project per month per app. The idea is to share revenue with developers, like Apple does it for iOS.

The name of the market place is ☞ Tadagraph, but right now it doesn’t seem to be anything in there. Time will tell if this is one future for CouchDB and CouchApps.

Original title and link: CouchApps Marketplace: A (Possible) Future for CouchDB (NoSQL databases © myNoSQL)


The Protovis CouchApp

So you have lots of data, you’ve made some nice views on that data in CouchDB and want to visualise it. Sure you could use some server side scripts to take the CouchDB view out and make a plot, but that’s not cool these days.

Not very advanced, but still a nice CouchApp: ☞ live plots.

Original title and link: The Protovis CouchApp (NoSQL databases © myNoSQL)


Couchapps Advantages

James Westby says ☞ couchapps show two immediate advantages:

Firstly, the ease with which they can be developed and deployed. As they are served directly from couchdb they require little infrastructure, and the couchapp tool allows for a rapid iteration. In addition, the conveniences that are provided mean that simple things can be done very quickly with little code.

The other thing that makes couchapps attractive is that they live inside the database. This means that the code lives alongside the data, and will travel with it as it is replicated.

Definitely an interesting architectural approach.

Original title and link: Couchapps Advantages (NoSQL databases © myNoSQL)


Couchappspora: Sort of compared to Twitter

Via Mark Essel:

The couchapp allows anyone to register and begin posting so try it out. There’s no federation yet, but additional couch databases can be continuously replicated. The distributed nature of the application spawns by setting up two way replication or synchronization between multiple nodes. This is one of the benefits of couchDB that makes it a great system for media sharing, and why I’ve decided to build on it.

☞ couchappspora has more or less nothing to do with Diaspora, but rather with ☞ (ex Identica) compared with ☞, aka federated vs centralized.

Original title and link: Couchappspora: Sort of compared to Twitter (NoSQL databases © myNoSQL)


CouchDB: A CouchApp Tutorial


I enjoyed using CouchDB, but ultimately found that MongoDB better met my needs.

The post is actually a great CouchApp tutorial, but I cannot stop wondering what was it. Being written back in April, before either CouchDB or MongoDB supported sharding, makes me think the reason was in the feature sets (can it be the MongoDB queries vs CouchDB MapReduce?) or speed.

Speaking of CouchApp, there is also this other extensive Evently tutorial: ☞ Do it yourself.

Original title and link: CouchDB: A CouchApp Tutorial (NoSQL databases © myNoSQL)


Node.js + Redis + CouchApp + BigCouch + CouchDB + TurnkeyLinux = Nirvana?

On Hacker News:

The reason for doing things this way is to make continuous deployment easier, but also to never have to reboot or change e servers much. The node.js services will be well tested and unchanging.


This should reduce maintenance to the bare minimum,and I can push out a new set of appliances over time and slowly migrate trafic to them once or twice a year when I need to update core funcationality.

Sounds like a cool combination, but I doubt that maintaining 4 different pieces will end up being as easy as he thinks it will.

Original title and link: Node.js + Redis + CouchApp + BigCouch + CouchDB + TurnkeyLinux = Nirvana? (NoSQL databases © myNoSQL)


CouchDB Case Study: Thingler, Collaborative Todo Lists

The data-model of Thingler was really simple: there was only one type of object: the Room (essentially a passworded list mapped to a url). The document-store aspect of CouchDB worked well, the application could store all the information in the room, such as the items in the todo (and associated tags), the password, the name and url of the room — in a single document, that was one GET away. The nice thing about this was that the document _id was also the URL of the room. To generate the URLs, the application just used Couch’s _uuids API.

Question to the experts: why using node.js and not CouchApp?

Original title and link: CouchDB Case Study: Thingler, Collaborative Todo Lists (NoSQL databases © myNoSQL)