We are looking to find the best way to store user options (skills, degrees, industries, languages, etc.) for drop downs. The options are between a JSON file we can store on the server file system or in the db (MongoDB).

What are the pros and cons of each method and how will they affect server performance under heavy usage?

closed as too broad by Ixrec, Dan Pichelman, gnat, Eric King, Doc Brown Jun 10 '15 at 21:14

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    File system vs. database Google search. Lots of articles to read. The answer is that "it depends" upon a lot of factors that are unique to your particular application. – jfriend00 Jun 10 '15 at 2:26
  • ​​​​​​​​​​​​​​​If you need to query the data, the answer is always db. If not, just pick one and move on. – yannis Jun 10 '15 at 4:01
  • just a quick clarification question. Are you asking about storing the json file on the client or the server? – RubberChickenLeader Jun 10 '15 at 17:47
  • @WindRaven on the server. – Kenroy George Jun 10 '15 at 18:14
  • 1
    recommended reading: What is the problem with “Pros and Cons”? – gnat Jun 10 '15 at 18:31

In order to make this more on-topic, this is a way to go about determining which one is better for a particular situation. Note: you may find that the best solution could change over time as your application's requirements change.

Do Both: Sorry, if you want to really find out the best solution, I recomend doing both and comparing your results. This accomplishes a few things:

  • Performance comparison (Assuming you can simulate a load)
  • Learn how to implement both in case you need to change.
  • Design your code so swapping data sources is not that difficult.
  • Part of this process could be used to create a unit or integration test.

Again, this is all predicated on not know which one will work for your situation, so you build your app in order to change the data sources as needed. You may find a need for some sort of in-memory data caching for this sort of thing. You'll be ready to do this without a major change to your application.

  • Yup, make a generic interface for your options so you can use either a database or a file-system. – Pieter B Jun 10 '15 at 20:04
  • @JeffO Thanks! I will indeed do a combination of both: large menu options will be stored in the db while shorter lists will be stored on the file system. – Kenroy George Jun 11 '15 at 19:44

There are very good arguments for and against each option. If you were speaking with regards to configuration data I would think a longer and more in-depth discussion would be warranted.

Since you're talking about application data, I would be inclined to believe that unless you know for certain that these data would never need to be queryable for reports and/or that it was static data that would never change, this data should belong in the database.


Json Way


  • Faster than DB
  • There is no weight for server/job


  • Update/Edit content is difficult.

DB Way


  • Can be develop for speed


  • Sometimes its unnecessary if it isn't change.
  • If its grow, it will weight for server

My suggest is using DB. Because you can develop for speed. Generally, I'm using JSON for static weight contents.

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