Ive been programing a C++ game/server for the past year. I have been using MYSQL for character logins, items, monsters, etc, etc. (im on windows). My question is, what are some of the databases that some big time developers use. IE. Battle.net, Diablo II, Diablo III, mythos, hellgate , etc, etc, etc. Do they have their own database they built? Or do they use an existing framework for logins, and character transfers.

I do know that in diablo II, they use character files to to transfer characters into the game world. But what about the login into battle.net.

Would it be wiser for me to stick with MYSQL, or is there something out there faster and more stable, or should I create a login type of system that looks through a file to see if you provided the correct password.

Can't wait to get some replies. Thanks!

PS. Currently the framework is much like battle.net, where you login into a lobby, create, and join games. The game server/lobby server are different servers too. So im just wondering about the lobby server for logins because I'm expecting several hundred thousand connections/logins.


2 Answers 2


Although not an exact duplicate, you are basically asking this question: What kind of databases are usually used in an MMORPG. There are several good answers there and the overall summary is "all of them" - ie. some use off-the-shelf DBs (relational or NoSQL), some make their own, some use traditional databases but treat them just as places to store binary blobs of data, and some use a mixture of the above.

MySQL is likely to be good enough for your needs. If it has worked for the last year, it's unlikely to stop working now.


There's not much use reinventing the wheel, you're likely able to use an off the shelf database for pretty much anything you need and the time you save instead of developing your own is invaluable.

I think that perhaps sticking to one database is less than optimal, MySQL is good for things like user logins, and such interactions, but I'd personally store character profiles in something a little more dynamic, the various nosql implementations in particular, as it's not likely you'll be doing much relational work with them.

Internally, an SQLite database for weapons may make more sense, as you can pack it in a file, and not have to worry about setting up servers and so on with the client's machine.

None of this is set in stone, but I don't think looking for a one-size-fits all solution is the answer.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .