Well, with SQS I suppose you have a more mature, but proprietary SaaS product. Also, almost every language has SQS libraries.
With CQS, it is of course younger and less mature than SQS; but you can use any CouchDB server to host the queue(s). The only implementation is Node.js, (a browser version is at beta quality). Using your own couch, you are responsible for it, but you are master of your destiny. For example, you might write a web report to summarize your queue and job status--a 100% Couch app. So I guess in summary, if you are already using Couch, CQS adds very little cost. If you are not yet using Couch, it adds more cost, and that factors into your cost-benefit decisions. With CQS, you would have a more intimate relationship with the maintainer (me!). I am eager to find and fix bugs but I am not a multinational technology-retail company. If somebody wants to implement another language binding, I would gladly document the architecture. It is very simple. CouchDB is extremely similar to Dynamo. I wrote the first release from scratch in two days, and added support for all browsers three days later. I wrote an Erlang "send-only" implementation in a few minutes (you just create a document that has certain fields set.) OTOH, with SQS, you have something largely bug-free and nobody from SQS or AWS will ever know you existed. On Tue, Jan 10, 2012 at 5:34 AM, Mark Hahn <[email protected]> wrote: > Thanks. That sounds perfect. > > I'm on amazon and I use couch. What are the advantages/disadvantages of > SQS versus CQS? -- Iris Couch
