We are building a real time banking platform and app.

Our prime concern is safety and consistency of our data across multiple db servers. We need transactions and we can't afford to risk power outages and lose our data (I'm talking about MongoDB). Our secondary concern is schema - like functionality for our app tenant users.

We also would like to escape schema updating hell on large databases. Custom schemas for our tenants is optional but very desirable.

We are very heavy AJAX frond end and our backend is full nodejs. We do a lot of JSON data processing.

Should we go with MySQL? Is there any noSQL solution (maybe CouchDB?) for our case?

Thank you for taking your time with this question!

  • 12
    The short answer is don't use MySQL or NoSQL in banking apps. MySQL isn't fully ACID (even InnoDB). No major western bank uses either technology for their ledger or trading systems. – gbn May 1 '12 at 5:27
  • 8
    Please tell me the name of this bank so I can ensure never to bank with them! ;) – Philᵀᴹ May 1 '12 at 9:02
  • 5
    Also, if you want "free" then use PostgreSQL: the choice of many hedge funds. – gbn May 1 '12 at 10:14
  • 2
    Also bear in mind you get what you pay for to a large extent. If consistency is critical, an open-source solution may not be the best choice. – JNK May 1 '12 at 13:32
  • 4
    I would check with your auditors before using such a thing as a nosql database for banking, they will probably have heart failure. This is a VERY POOR idea. And it's not just ACID, you really need strong internal controls in the database itself. – HLGEM May 1 '12 at 15:16

As far as I know there are no "nosql" databases that promise ACID transactions, so for banking purposes they are a non starter. Referential consistency support is not usually in their key feature sets either.

mySQL claims ACID transactions when using innodb tables, but I believe there are some caveats around that which may be show stoppers (any mix of other table types, including in-memory tables which are sometimes used for intermediate results in complex logic, will break ACID compliance for instance).

If you are looking at these options because they are free, then consider postgres which does offer ACID transactions, even including transactions that make schema changes. Please consider your support SLAs though: if this is a system that needs high availability (and the words "realtime" and "banking" suggest it is) then I recommend having a support contract in case something beyond your understanding or access to fix goes wrong. This will be rather expensive and once you are talking about that sort of money you might as well at least consider commercial database servers too.

One final point not relating to any particular database: make sure you have the right options selected for full ACID behaviour. A lot of systems default to settings that bend the isolation part, because guaranteeing complete isolation often requires serialisation which can significantly impact the performance of concurrent operations. Whatever DBMS you chose make sure that you understand its options for isolation/serialisation (like "SET TRANSACTION ISOLATION LEVEL" and related directives in MSSQL) and how they interact with each other.


There is GT.M: http://www.fisglobal.com/products-technologyplatforms-gtm

The database engine, made open source in 2000,[1] is maintained by Fidelity Information Services. GT.M is used as the backend of their FIS Profile banking application,[2] and it powers ING DIRECT banks in Spain, France, Italy, Holland, Romania and India; Capital One 360 in the United States; Tangerine (Scotiabank) in Canada; Scottish Widows and Barclays Direct in the UK. http://en.wikipedia.org/wiki/GT.M

I don't know about commercial support but in any case you should have a solid grasp of the ACID meaning and deep technical know-how to work with this or any database that you may use for this kind of applications.


While MongoDB's lack of transaction support was certainly true at the time of this question, in an upcoming release in June 2018, MongoDB will support multi-document transactions: https://www.mongodb.com/transactions

  • Would you then use it for a banking solution? – dezso Mar 6 '18 at 8:05

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.