# Persistent Data for Multiplayer, Browser-Based Games

What is generally used to store persistent data in online games - browser games/facebook apps, in particular?

I have used MySQL in web development before - but I've read that it's not very scalable, especially if many transactions are happening constantly (which is what will happen inside of a game).

I'm writing the back end in Node.js using Heroku, so it would be really nice if there were a Node package to go with it.

Any insight would be much appreciated.

• There isn't much to be said here that isn't already found here (gamedev.stackexchange.com/questions/2282/…) except that web developers tend more towards standalone databases. – Kylotan Jan 3 '13 at 19:18
• @Kylotan It seems like the author of that top answer was leaning towards NoSQL, but MySQL is still the way to go – funseiki Jan 3 '13 at 19:31
• It's not just the top answer there that you need to look at. Basically game developers use a variety of technologies depending largely on personal preference and experience. MySQL is perfectly good, as are other RDBMSs, or NoSQL systems like Mongo. – Kylotan Jan 3 '13 at 21:00
• It really depends what you're doing. Depending on how your game operates, it's unlikely that you're going to want to save data into the database very often. If you have real-time game data, they're probably going to be at least initially in ram in a custom-written server process. Longer term data don't need to be saved so often (not every 1s, certainly) – MarkR Jan 3 '13 at 22:48
• @funseiki - there's no clear choice here as it depends on several things: your development team's preferences and experience, the type of data you want to store, how often you're storing, write:read ratio, how often you expect to change the schema, whether you need external access from other processes or not, etc. The game specific parts are minimal really. If you really don't know, just start out with MySQL because your familiarity will help. – Kylotan Jan 4 '13 at 4:15

You can find one nodejs mysql pack here https://github.com/sidorares/nodejs-mysql-native To scale you can use shards, partitioning, replication (with read only instance), try adding some cache layer like memcached ... (not game specific - there is an article from facebook showing how they scaled mysql) The database choice heavily depends on your data modeling. If you need to scale at high rates, consider using some kind of nosql database (in games, some key value based db like redis can help you a lot - it also integrates nicely with nodejs http://redis.io/clients)

• I've never used memcached before - but I hear that redis+mysql would also work. I think I'll start with the mysql pack with node and go from there. Thanks for the links. – funseiki Jan 3 '13 at 19:48
• This advice is probably not helpful. People shouldn't be encouraged to use partitioning, replication, and especially not shards. Also the caching you mention only works with mostly-read-the-same-unchanging-data workloads, e.g. Wikipedia. – MarkR Jan 3 '13 at 22:46
• Why not ? These are the tools that help scaling relational database. The part of cache is obvious correctly, all caches helps only if the operations are mostly read. (as most application are) – Tpastor Jan 4 '13 at 16:03

If you want to persist the data with the user you can use localStorage. It's pretty simple to use

windows.localStorage['myvar'] = 'some data';


There are two downsides tho.

1. Almost all browsers limit you to 5m of data
2. You can only store strings which means you will need to stringify any objects you want to store.
• I want the data to persist on the server, not locally. E.g. A player's username or experience points – funseiki Jan 3 '13 at 18:52

Well, the load of the DataBase depends a lot of what kind of game you want to develop, in some cases MySQL or Postgres will do, but assuming the worst case MongoDB is a very good solution, plays nice with Node.js, scales horizontally, and has useful features for VideoGames as geospatial indexes.

Take a look at the use cases.

PD: I have seen blogs posts about Heroku + Node.js + MongoDB.

• What is the worst case and how will MongoDB do it better? – funseiki Jan 4 '13 at 2:05
• The worst case is a game with high number of small reads and writes, MongoDB is designed with that in mind, you don't need to batch any query (See uses cases), plus is efficient storing heavily structured hierarchical data which is very common in complex games. – Oliver Jan 7 '13 at 20:20