I am working on a personal finance management application, which will also analyse the user's financial statement and give a good overview about their expenses and savings.

What I am having trouble is choosing between SQL and NoSQL. As per the data it looks very straight forward when using relational database managing the transactions and the user data. When using non relational approach de-normalizing the data might be a problem because there are a lot of referencing to transactions, category, modes and more.

What would be a good approach to this?

*Note: We are planning to use MEAN Stack for the app

  • I'll say NO, as NoSQL (by no-sql I mean database that enforce eventual consistency) are good if you have a really high (amazon level) number of transactions per second, for personal use structured data is by-far much better as it keeps consistency across the data. If you have a wide-scale app with centralized analysis, No SQL may be the way, but for medium scale, regoular BI system should be enough – DDS May 28 '18 at 8:11
  • Thanks, but what if the app is being used by 1000 or 10000 personal users ? then the transaction per second may increase. The main reason of thinking about NoSQL is scalability. – shankara narayanan May 28 '18 at 8:25

The first thing you should do is to read this (from 2010). If that doesn't convince you, the read this (from 2014) and this (from 2017). Developers are discovering that SQL, transactions and consistency weren't such old-hat after all!

NoSQL is a tasty soufflé composed of more air than substance. There are some cases for which NoSQL is a good fit, and those are NOT finance management apps!

You abdsolutely want strong consistency for anything to do with monetary activities! NoSQL is one of those industry bandwagons which come along from time to time, like a star which is about to go supernova, briefly shines brightly, only to explode, then withers and dies a lingering and painful death much like a white dwarf!

NoSQL paradigms are good for social media type sites (i.e. the user typically isn't paying anything, or for only a small subset of services) where absolute consistency (through proper transactions) isn't a priority.

Systems such as marketing and/or analysis and/or reporting apps could be NoSQL. However, SQL is also great for slicing and dicing data for marketng, analysis and reporting. See Brian Aker's (former MySQL chief architect) hilarious take on NoSQL here.

From a similar thread about banking, there is a suggestion that NoSQL could be suitable for banking if the system has strong consistency and transactions - which brings us back to the RDBMS anyway. This is sort of the point of the 2014 link above - i.e. that NoSQL systems are all trying to put a strongly consistent SQL layer above their systems - we're back to the classic database: It's like déjà vu all over again :-).

Take a look at what Michael Stonebraker - a man who knows a thing or two about databases calls NoSQL a giant step backwards. He proposes "NewSQL" which "all support the relational data model and use SQL as their primary interface".

Re. MEAN stack, there's nothing wrong with using JavaScript frameworks for your front-end, just change the backend to an RDBMS. You should let the functionality decide the stack, not the other way round! If you want to go with Open Source, then my recommendation is that you use PostgreSQL (the best one in the field but a country mile!).


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