MongoDB was initially added to our stack 2 years ago
for our currently on-hold Tracks project. With some initial success, we quickly
migrated over some of our other persistence layers; blog
documentation and other tools.
After 2 years we’ve discovered that while MongoDB is very good at certain
things, it is ultimately not solving the problems we need it to.
Last August I wrote a blog entry about making the move from MySQL to
and listed some key points outlining our decision to rely on it.
Most of the changes we have wanted to make to the Forum required schema
changes which would have been much more work with our data in MySQL
After deciding on our final schema to represent threads, we realized that the
data is ultimately relational, and storing in an RDBMS is simpler than leveraging MongoDB’s two
ways of solving one-to-many relationships; Embedded
MongoDB has full text search capabilities out of the box.
We quickly realized that these search capabilities were beginning to hold us
back. Our blog and forum search have been lacking for a long time, and we want
to make it better. We need support for things like advanced tokenizing and
stemming, built-in capabilities for faceting counts and “More like this”
features. Things that another dependency in our stack already provides,
The Forum is now stored in it’s own dedicated “cluster” which allows for
scalability via our N+1 architecture, and will not impact the rest of the
Aside from the occasional replication lag issue, messing around with a wonky
mongod process, or accidentally locking up the entire replica set, MongoDB
hasn’t given us many operational issues.
We’ve ultimately decided to migrate our data back to our primary persistence
layer, and to better leverage another dependency in our stack (MySQL, Elasticsearch).
This is going to result in much faster load times across the
site and an improved search interface for our
Help Documentation and other tools with better