Million Dollar Mongo - Obie Fernandez (Hashrocket), Durran Jordan (Hashrocket) mongo was a good choice because only one patient record was worked on at a time get entire object graph in a single query previously did 35 joins and took 20 minutes to return comparison between mongo, couch & cassandra big selling point was dynamic queries - nice happy medium when coming from relational databases “I don’t want to write any more ** XML, so goodbye Cassandra” No universal agreement that a NOSQL solution was the right idea “Easiest database to install ever (except maybe Redis)” No schema migrations Forked MongoMapper -> Monoid - MongoMapper was very young Mongoid - Prefers Embedding Documents - Atomic Operations by Default, based on attribute changes - rich criteria api - master/slave suppor - simple versioning - is NOT ActiveRecord (and should be treated as such) - Features always have performance in mind mongo - can index in background as of 1.4 regex queries on fields Denormalization is acceptable, embed as much as possible (no FK constraints) Hybrid DB model - Hierarchical Data Stored in MongoDB - Relational Data stored in MySQL - Data that required transactions stored in MySQL - Simple Data in Redis - Favor suitability over simplicity It’s ok to use more than one datastore Working without transactions - Atomic updates generally cover you - fairly easy to roll your own optimistic locking - need to do manual rollback in integration tests - selenium tests can run in a separate process in production - deployed on engine yard cloud / ec2 - 0.5 TB of data - put mongodb on it’s own utility space - feed it lots of ram, lots of disk space - chef scripts easy due to simple installation