The answer is yes, it's a valid option but no, it probably isn't a great idea.

There are two major problems with SQL that NoSQL tries to address, when it comes to games.

The first is latency, or lag. In one sense, SQL databases are blazingly fast, processing thousands of transactions or more in tenths of a second. In another sense, they're incredibly slow, because processing just a few transactions can take that same amount of time. For most database uses, this doesn't matter, but games have a real-time component so it's not just about how many transactions you can do per second, but about the average time it takes to respond to a database transaction.

This latency is a major problem for real-time games. Many developers that need large databases (usually for MMOs) build out a caching layer that sits between the database and the game servers in order to avoid these stalls, and then flush the cache periodically. The problem? You just threw out the main reasons to use a database - atomicity, consistency, isolation, and durability.

But that problem doesn't apply to web games. You've already got a high-latency connection between the player and the game, so you might as well get the throughput SQL provides, as well as the benefits of mature, well-known software.

The second problem, however, does apply to you, and that's the object-relational impedance mismatch. Games deal with objects, databases deal with rows. If you're lucky an object can be made into a row just by listing its fields, but most of the time objects are hierarchical, and you've got to flatten them out in some way to get them into rows.

Document-based databases, like CouchDB and MongoDB, solve this problem by promoting the document to the top-level object, rather than row ("document" in this case is a synonym for "object"). But by doing this, they lose many of the benefits of SQL databases. The throughput is much lower, and the locking algorithms become much more complicated.

The good news is, there are already a lot of object-relational mapping (ORM) tools available for whatever language you're using. They let you translate between objects in memory and rows in the database fairly transparently. These tools are generally not appropriate for large-scale real-time games, because they can present the worst performance aspects of SQL and NoSQL databases. But it's fine for a web game - at worst, when you run into performance problems, you can go back to doing transactions the old-fashioned way. The latency problem doesn't hurt you, and the increased throughput helps you.

Finally, to belabor a point I've made elsewhere: This isn't about static game data. I'm not talking about your item descriptions or your weapon damage or sprites or anything here. I mean the real, mutable game data, like what's in a player's inventory or what their stats are. All you need for the static data is a data store. Maybe it turns out that the easiest thing to do is use the same database as the data store for that because you have a great ORM; maybe you'll just need the filesystem. It's two separate problems, and one answer needn't (and probably won't) fit both cases.

The answer is yes, it's a valid option but no, it probably isn't a great idea.

There are two major problems with SQL that NoSQL tries to address, when it comes to games.

The first is latency, or lag. In one sense, SQL databases are blazingly fast, processing thousands of transactions or more in tenths of a second. In another sense, they're incredibly slow, because processing just a few transactions can take that same amount of time. For most database uses, this doesn't matter, but games have a real-time component so it's not just about how many transactions you can do per second, but about the average time it takes to respond to a database transaction.

This latency is a major problem for real-time games. Many developers that need large databases (usually for MMOs) build out a caching layer that sits between the database and the game servers in order to avoid these stalls, and then flush the cache periodically. The problem? You just threw out the main reasons to use a database - atomicity, consistency, isolation, and durability.

But that problem doesn't apply to web games. You've already got a high-latency connection between the player and the game, so you might as well get the throughput SQL provides, as well as the benefits of mature, well-known software.

The second problem, however, does apply to you, and that's the object-relational impedance mismatch. Games deal with objects, databases deal with rows. If you're lucky an object can be made into a row just by listing its fields, but most of the time objects are hierarchical, and you've got to flatten them out in some way to get them into rows.

Document-based databases, like CouchDB and MongoDB, solve this problem by promoting the document to the top-level object, rather than row ("document" in this case is a synonym for "object"). But by doing this, they lose many of the benefits of SQL databases. The throughput is much lower, and the locking algorithms become much more complicated.

The good news is, there are already a lot of object-relational mapping (ORM) tools available for whatever language you're using. They let you translate between objects in memory and rows in the database fairly transparently. These tools are generally not appropriate for large-scale real-time games, because they can present the worst performance aspects of SQL and NoSQL databases. But it's fine for a web game - at worst, when you run into performance problems, you can go back to doing transactions the old-fashioned way. The latency problem doesn't hurt you, and the increased throughput helps you.

Finally, to belabor a point I've made elsewhere: This isn't about static game data. I'm not talking about your item descriptions or your weapon damage or sprites or anything here. I mean the real, mutable game data, like what's in a player's inventory or what their stats are. All you need for the static data is a data store. Maybe it turns out that the easiest thing to do is use the same database as the data store for that because you have a great ORM; maybe you'll just need the filesystem. It's two separate problems, and one answer needn't (and probably won't) fit both cases.