Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Developing an iOS/Android/WP real time game.
Server side stuff will be done in Javascript using Node.js.
It will be a trivia with 8-players rooms + an admin site made in Python with Flask (for stats, account management, adding questions... It will also provide an API to get user profiles).

Basically I will have to fetch around ~10 questions/game (I will be checking if users already answered them or not so I can avoid redundancies too).
I was wondering if my project would really benefit from a nosql db.
I have never used one but wouldn't mind learning if it is relevant.

Player data : classic account infos, score, answered questions...
Questions data : questions + translation, answers, stats (times asked, correct/wrong answers count)...

RDMS choice would be psql.

Any thoughts? Thank you

share|improve this question

The short answer is that NoSQL, NewSQL, OODB or just plain SQL are all options, but SQL is probably the most viable. Many NoSQL implementations can be configured for ACID compliance at the cost of performance/scalability, but they will most likely still scale beyond most reasonable SQL implementations. Another option is to use application sharded SQL to get scalable SQL with minimal effort/cost, and in many cases is very viable. Generally the architecture and testing is more critical than the data store, the most scalable data store may fall flat on its rear with the wrong architecture.

For a startup, getting the product out is often the primary consideration, and SQL is generally the quickest to market due to it being a known entity and experienced developers have the most experience with it. The biggest problem is usually your available resources, do they have the knowledge and experience with NoSQL? Or do you have the time to test, configure, test again?

pSQL is relatively known, its limitations are known. NoSQL has 10s of viable options, and 100s in some state of development. Finding the right one and understanding its limitations is a pretty significant project by itself. NewSQL is very new, in 3-5 years it may very well be the defacto DB for large scale projects. Any small shop should probably stay away until it gets more significant production usage by larger companies that have the resources to diagnose and work around the inevitable problems.

share|improve this answer
this is actually a school projects so there will be no such thing as some experienced devs knowledgeable of nosql in my team. I guess I will stick with psql as we already know it and it will help us deliver our project faster than if we were using a nosql db. – rxdazn Feb 27 '13 at 19:45
If you are concerned about performance and the application has natural sharding (i.e. independent game rooms) then I recommend building in application sharding, it will at least allow you to scale relatively easily. Example: Use game room as key, Hash the game room ID to evenly distribute the location between servers deterministicly It sounds like you accepted this as the answer, if so please mark as the accepted answer. Thanks. – AceCTO Mar 2 '13 at 16:11

I think the first thing to do is make sure you know exactly what you need. Chances are you want to start with SQL as AceCTO suggested. My reasoning for starting there is different however.

The basic point is that standard SQL is a pretty mature technology. You know what you get. It is robust also, so you don't have to deal with the questions that things like VoltDB (a "NewSQL" solution) bring up regarding durability of your data. VoltDB is ACID-compliant for some values of C and for some values of D, but those values are non-standard. If you need to move to it you always can, possibly as a helper for a standard RDBMS. NoSQL is fragmented, but the tradeoff is more basic.

With NoSQL you are typically moving from a relational database which specializes in flexible, well-contracted data output to a non-relational database that specializes in flexible, vaguely-contracted data input. This tradeoff is massive. It means, on the positive side, that you can just throw data at the database and not worry about whether it is valid or not. On the negative side, not only does it mean you can throw data at the database without worrying about validity, but it also means that that you are giving up on set-based manipulation of the data using well-structured mathematics. These are massive downsides and almost never worth replacing an RDBMS with a NoSQL solution.

As for scalability, on good hardware, PostgreSQL can scale up to a hundred thousand transactions per second on TPC-C tests. Additionally even if you dont want high-end hardware, you could scale outward with Postgres-XC if you need to on smaller servers. Additionally your check for whether a player has seen a question is likely to be set based and far easier to do in a way that performs well than you would with a NoSQL solution.

Long-story short, start with SQL. You can always add helpers, whether NewSQL or NoSQL as you need to, but chances are relational math is too valuable to throw away.

share|improve this answer

To be sure that your statistics and player data are correct I would go for a database with true ACID transactions. If a player updates data from different threads/sessions you want to be sure the data is consistent. Also getting duplicates of messages due to incosistent data will make the player grumpy.

In a game, even with extremly huge number of players, I do not think you need a big data NoSQL database (PB of data).

I like that you have looked beyond the traditional RMDBS! Have you checked any NewSQL databases? There you will get the performance, TB of data storage, ease of use as a developer alongside true ACID transactions.

share|improve this answer
Will a RMDS be fast enough if multiple game rooms (we're hoping for 100s, maybe 1000s) are running simultaneously? I'm not sure about NewSQL. It seems too recent to me, a bit too risky. – rxdazn Feb 27 '13 at 19:48
You do not need to be scared about the stability of NewSQL databases. If you look at Starcounter, for instance, it has been live in production environment for years. I cannot give figures for other NewSQL databases, but Starcounter can manage 500 000 read-transaction per second and core (scale linear over the number of cores) and 300 000 write transactions per second. – Niklas Bjorkman Mar 5 '13 at 9:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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