Are there any pratical examples of database implementation for an MMORPG in CouchDB? Even a detailed thesis? I've looked but found very little on practical examples and not even find any good UML examples and plus I see a little bit of an issue with the lack of schema and design by UML. Maybe It's more of a paradigm change but I'm ideally looking for something that has things like:

Users Quests (multipart states) Characters NPC states Items

Just to get started...regards

  • 7
    \$\begingroup\$ Same way you design any other database, make sure you have got an index for all ways you wish to access data. The slightly more tricky part is figuring what to put in the database and what to keep in application memory. Apart from that there is only the same thing that can be said for almost all MMO questions: If you need to ask, you should not be developing an MMO. \$\endgroup\$ – aaaaaaaaaaaa Jan 13 '12 at 23:23
  • 1
    \$\begingroup\$ Yeah - game design comes first, then data design second. Once that's done you know what you need to store and whether you use CouchDB or MySQL or flat files becomes a largely irrelevant detail. \$\endgroup\$ – Kylotan Jan 14 '12 at 17:59
  • 2
    \$\begingroup\$ I'll just add that people are as funny about their MMO pixel items as they are about real cash, so whatever you do if it isn't ACID you're just playing with fire and you will get burned. \$\endgroup\$ – Patrick Hughes Jan 15 '12 at 0:00

With a NoSQL database, you are able to more directly map your application data to your datastore. Object-relational impedance mismatch isn't any issue, and as such you can create a more direct relationship between your application's class design and the schema of your NoSQL database.

Example, for a hypothetical Player class, which may contain complex data structures, attempting to store that data into a relational database would require a complex database schema, as well as complex wrapper classes in the game's actual code base. Almost all of this complexity is removed when storing into a NoSQL datastore. You can develop Entity groups that mirror the structure of your game's Player class.

Using NoSQL for MMOGs is still a fairly new concept, because you do lose complex SQL querying which are critical for game designers, and most NoSQL datastores don't offer transaction support, which is another major omission. That said, be sure CouchDB meets the needs of your game, as choosing the wrong database solution could have dire consequences.

I recently wrote a blog post about why we chose to use Google App Engine as our database solution, and I'll be delving deeper into our actual application design and implementation details in later posts, if you want to keep an eye out for them. Even though we are not using CouchDB, I think you may still find it informative, or at least entertaining ;)

Depth-First Design


It is certainly possible but I haven't seen any direct examples. A NoSQL database may be better for MMOs when we consider their scalability across multiple servers. SQL engines can do the same thing but generally require a whole lot more planning and money to do so.

Having messed around with MaNGOS' source (World of Warcraft private server) I can say that the majority of data used is loaded into memory when it is needed and there isn't a high complexity of relational data. Data written to the database is really just a backup for what is in memory. When data is no longer needed in memory it is dropped.

Database type is going to be dependent on how you structure your game engine. If you only load portions of your world at a time then you can just load and store that section of the game world. In that case just about any DB will probably work fine as long as you can quickly query out the objects in that section and quickly write them when you are unloading that section.


Please don't get confused by mixing scalability and SQL vs. NoSQL. There are several frameworks which can seize the power of either database system and they become quite easy to use. Scalability does not come from the database type but the system architecture (trust me, it is a myth that has been proven false several times).

Want scalability? Pick even a MySQL database and use replication (I think PostgreSQL is even better at that). Want fast-access? Use a cache layer (yes, I know these NoSQL databases come with built-in cache).

Please focus on this: You are not forced to use NoSQL for fast data access. OTOH if you want to access data maps (i.e. key => value pairs for each instance) Hibernate supports this.

Many popular frameworks can be integrated with CouchDB, MongoDB, or Relational Databases and you will likely use them as you use them always.

So my conclusion is: Your approach is wrong. Design the game first. Then use a well-known framework for data mapping. Then add a cache layer (controlled by the application if the database does not support that, but even in some cases you'll want another cache level for the application so be wary there). When designing your game you should not be focusing on the database internals. OTOH if somehow you are forced to use CouchDB, CouchDB and MongoDB are similar in the way that they store JSON documents with no referential integrity, but the way you model your game is not essentially different by using that database (except that, at database level, posession-related objects will literally belong to the parent object).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.