Bye, MongoDB. Hello, Cloudant

http://blog.postmarkapp.com/post/37338222496/bye-mongodb-hello-cloudant

by chinmoy • 14 years ago

150 44 14 years ago

blog.postmarkapp.com

d0m• 14 years ago

Cloudant seems interesting, never heard of them before. The pricing is intriguing. (https://cloudant.com/pricing/) From what I understand, it's free for most small projects but could get very pricey very fast, but then, handling millions of customers is far from being trivial to handle so I'm sure it's worth the price. Thoughts about the Cloudant pricing versus in-house solution (or vps)?

ahoff• 14 years ago

Our pricing as stated on the page can be somewhat confusing. We're working on making it both less expensive and more transparent to the end user.

pooriaazimi• 14 years ago

IrisCouch's pricing is also interesting: http://www.iriscouch.com/service

amaris11132• 14 years ago

I might also note, thats its worth contact Cloudant directly if you are working on a larger scale production app. We have the metered pricing listed on the website and then dedicated which is an "all you can eat" style service and you pay a flat monthly rate based on how many nodes are in your cluster. That is the system that Postmark is using along with most of our other bigger customers.

josh2600• 14 years ago

We run BigCouch from Cloudant and it's amazing. They are awesome folks and spoke at our conference last year.

https://github.com/cloudant/bigcouch

Disclaimer: I'm the community manager for http://www.2600hz.com

rdtsc• 14 years ago

I love CouchDB. There was talk on the mailing list and IRC channel about eventually merging in BigCouch with CouchDB code base. That would be awesome.

mlmilleratmit5• 14 years ago

That's well underway and planned for the 2.0 release of CouchDB.

chrissharkey• 14 years ago

We were running our own Bigcouch cluster and having all sorts of issues scaling to large numbers of databases (50k+), but after moving to Cloudant it handled it just fine.

It does cost more, but we don't worry about our database now and can focus on what we're actually good at.

Their search feature seems to be pretty good too. It is based on Lucene and is very flexible!

Chris Sharkey, Bislr

gingerlime2• 14 years ago

Interesting to find out what was going on behind the scenes at postmark. As a (albeit small) customer, we were noticing something was going on, but not exactly sure what. It's great to see the postmark guys sharing the info and being transparent. Overall I really like the service despite the recent issues.

As far as cloudant, I also never heard of it. Trying to go through the website, is this effectively a managed CouchDB in the cloud? Also, just wondering what's the migration path out of it (or who provides alternative service) just in case something doesn't work out.

mlmilleratmit5• 14 years ago

Cloudant sits under the Apache CouchDB API, so the easiest path for migration in/out of Cloudant is to use replication to/from another CouchDB-speaking service like Cloudant, Apache CouchDB, TouchDB (mobile), PouchDB (browser). For most databases, you can also get a JSON dump of the document bodies by doing: curl 'https://username.cloudant.com/dbname/_changes | gzip > dbname.json.gz.

The tricker part of course is understanding how to best model data as you move between different database systems. There are some nice tools emerging in the no/new-sql ecosystem to help with that. Here's one that some of our mysql/postgres converted customers seem to like: http://www.foxweave.com/moving-on-premise-data-to-the-cloud-.... My understanding is that it works in both directions.

cnagele3• 14 years ago

Chris from Postmark here. We definitely had some trouble over the last few weeks. I am hoping we are beyond that in terms of architecture. So far everything looks great.

Regarding lock-in, this was pretty important to us when we decided to migrate. We prefer to control everything in our data center, so if it came down to it, we wanted that option. Since the Cloudant API is compatible with CouchDB, the migration path is not that hard. Although, considering our impression so far and their expertise, I don't expect it will come to that point.

gingerlime2• 14 years ago

Thanks for the info Chris. I certainly hope you won't have to make another big move, but vendor lock-in is always a consideration. Also, I'm curious about network/other latency and bandwidth limits when it comes to accessing cloud-based database services. Did you do any measurements on that before or after switching?

...and regards to Natalie, Dana and the rest of the postmark team!

EDIT: noticed info about latency from cloudant on another comment.

thesis• 14 years ago

Can anyone share how latency is overcome using a cloud based database?

jameswyse• 14 years ago

It's not a problem if they're both in the same data center, not sure who cloudant are using though.

mlmilleratmit5• 14 years ago

(Mike Miller, Cloudant). Exactly, we run cloudant clusters in nearly 20 data centers globally on many different providers (ec2, softlayer, rackspace, joyent, azure, hostway, ...) so we make sure that the data and application tiers are co-located.

Dealing with direct connections from mobile is more fun.

spligak• 14 years ago

It isn't a problem if you're speaking specifically about Cloudant. They co-locate clusters next to your app as best they can (as Mike has mentioned elsewhere). That makes the network you're running on critical, however.

When we built out our message queue offering at SoftLayer (which uses Cloudant/BigCouch as a data store), latency out to the DB cluster simply never ended up being an issue. Properly leveraging DB features, I/O priority tuning, the caching tier behaving properly - all more often these end up being the culprit in performance issues.

What you need to better understand when considering a cloud-based data store is who's running your cluster. When it comes to guys like Adam, Mike and Robert, you're going to be very hard-pressed to find better (and available to you) talent in the CouchDB world. We certainly appreciate having them around.

benmccann• 14 years ago

I really wish they had been more specific about the problems they faced. It sounds like part of the headache was that they had to write their own MongoDB to ElasticSearch connector. However, 10gen has now written one which they could use to avoid writing and maintaining their own: http://blog.mongodb.org/post/29127828146/introducing-mongo-c...

cnagele3• 14 years ago

Hi Ben, the ES connector was part of it. At a certain point we had our custom oplog follower working well. After so many years working with MongoDB, we just lost trust in it, to be honest. We ran into so many bugs, replication issues (two secondaries and no primary) and the only way to get what we needed out of it was to use all SSD storage (Even flashcache did not work).

I have to admit that this was for our use case, and I know that MongoDB works extremely well for some people. We still use it in Beanstalk for our deployment logs and have no complaints. It's a much smaller dataset though.

Really nice to see that 10gen made an ES connector. ES is still young, but it's amazing. One thing that I always respected about 10gen is how they maintain all of the drivers and code.

neya3• 14 years ago

Is this going to become a trend here? Some random start-up writing "Bye-bye <insert database name>" or "Why we moved from <db1 name> to <db2 name>"??

georgemcbay• 14 years ago

Going to become a trend? Posts like this have been fairly common for years now.

neya3• 14 years ago

No, I meant the frequency of such posts have increased in the past few months..

pbbakkum2• 14 years ago

On Mongo: "we were not big fans of the master/slave architecture"

I don't quite understand this, that architecture was basically deprecated a while back, can you elaborate?

cnagele3• 14 years ago

Sorry, I need to correct that. I meant that shards are basically still primary / secondary with an arbiter for failover. We prefer horizontal nodes instead, like Cloudant, Elastic Search or Cassandra offers.

pbbakkum2• 14 years ago

Ahh, I see. Why do you guys prefer that configuration? Space/resources, reliability?

philfreo• 14 years ago

Can you elaborate on what you mean by it was deprecated a while back?

nsainaney• 14 years ago

We looked at MongoDB for our back end at http://moj.io and preferred CouchDB. It's currently a toss up between Iriscouch and Cloudant. Both seem like great offerings. We are particularly interested in the ability to sync to CouchDB on iOS/Android/Windows Phone in the future.

Does anyone prefer one service over the other?

zapfmann2• 14 years ago

Grr.. I can't figure if you can deploy cloudant in an on ec2 avail zone that you have your app in. Can you you even deploy it on ec2?

I don't see anything stating answers to these questions clearly on their site. And they want my email to let me see tech docs! Are they run by former IBM staff?

Finally, if they are 'hosted and managed all day everyday' some place far from me. I dunno if I want to use it.

zapfmann2• 14 years ago

Ah. Spoke too soon. The comments here lead me to believe cloudant is to be used as a couchdb replica provider.

Maybe cloudant should say that on their pages! :-)

Bye, MongoDB. Hello, Cloudant

Related Stories