Why you should not use nosql for financial transaction

Question

I heard from a speaker at a Hackaton event organized by a bank that you should not use nosql for financial transaction for security reasons. But I have no idea what he's saying. I have been looking for an answer as to why I should not use nosql database in my application.

What are the pros and cons of nosql, and what are the pros and cons about sql databases for financial transaction?

Now, I'm building an application for shop cashier, where the cashier will use this app to store transactions, receive orders, and receive payments with Cash or Credit Card.

What is the best possible approach for this project's API? SQL or NoSQL, and why?

Answer 1

AS explained by @A2H, the SQL and NoSQL depends on your requirements, saying that NoSQL is not secure is not accurate, this is like saying that SQL is not scalable... which is not true either.

Now, for a financial application you will have some non-functional requirements that I can list below:

• Secure at file level: if someone has access to the database file will they be able to use this to load the information somewhere else? for example, in SQL Server the login information about the db is included in the files, therefore copying the files without the password will make hard for hackers to steal information.
• Scalable: How much,are we talking about? some millions records? Scalable in what sense, do you require to do distributed queries or just localized databases depending on the region and central tables for accounts info? or are you planning to create an application that will receive tons of records per second (like forex information) and therefore you need something to ingest tons of records and analyse results? in that case maybe NoSQL is for you.
• Transaction (ACID) complaint: Are you handling transactions (like the type of debit this credit this other?) then you might need to use something like Djondb or traditional RDBMS, both support transactions.
• Flexible schemas: You need a flexible schema that can adapts to your frequent changes without having to redesign your database and updating previous records? NoSQL is good at this.

the list will continue... but I think you get the idea...

Saying that NoSQL is un-secure is an overstatement, as any other generalisation.

Answer 2

SQL and NoSQL databases are not interchangeable. There's no silver bullet database technology. You should consider pros and cons when choosing what database technology you want to use for your project.

Short answer: If you need to process transactions, your data can nicely be arranged in relational entities then use SQL. If you need to handle large volumes of semi-structured or unstructured data, and need horizontal scalability, then use NoSQL.

If you want to read more about differences between SQL and NoSQL click here or here.

Some insight on when to use SQL or NoSQL can be found here.