What are other options for storing data in a web application besides a database? [closed]

Question

I have a pretty small database (15 tables, ~1000 rows) that is being accessed very frequently to get data. I was wondering what other options besides a database I had for storing the data and accessing it?

Answer 1

TL;DR; Unless you have a really imperative reason to organize your data in a different way just go with the relational DBMS option instead of trying to reinvent the wheel.

In terms of data a relational database is, almost always, the best option. Is been optimized for searching and has a relatively good performance for inserts and updates while at the same time maintaining a reasonable level of structure, as well as adhering to a series of normal forms to enforce structure and good design decisions.

---

A "data" "base" is always required when you're storing data in a structured organized way. So you'll always need a database, the actual implementation of the database and the way the information is organized is called DBMS (database management system) and in that sense you have a lot of options.

Out of the top of my mind, in terms of the way the database is organized you have non-relational databases (usually called NO-SQL database)

• Document-oriented databases.
• Graph Databases
• Key Value Store databases

to quote a few.

You have several relational DBMS at your disposal:

• Oracle
• Sql Server
• Postgree SQL
• MySql
• Sqllite

And even other kind of DBMS which are not generic but application specific.

In general, your choice of the backend database should be determined by your necessities now and what you think you'll need in the future in terms of:

• The data that you're going to maintain and manage
• How you think about the data
• Performance restrictions and non functional requirements.
• The level of familiarity of you team with the new technology versus the well know relational-sql pair.
• The logical organization of the data and how you plan to access it.

Answer 2

Tjameson is right, you can use an in memory store to either act as the authoritative database, or as a cache for a database.

Obviously the in memory database is most likely too volatile for permanent storage if it isn't flushing data out to disk from time to time. A reboot will kill everything.

I would also agree with tjameson that maybe the problem is somewhere else.

Best way to debug production issues is to get data, data, data. The problem isn't always where you think it is.