Another option—one that is probably not going to work well for large quantities of data, or under significant concurrent user-load—is simply to store application data locally as one to many files on the local machine. With the advent of simple structured data representation formats such as JSON, this can be a better option than it might seem at first glance, at least for certain needs: JSON, in particular, with its basic value-type support and the ability to represent arbitrarily complex or large data structures, is a reasonable storage format.

The most significant impediment is making sure that data access has at least some degree of ACID compliance, though, as with NoSQL databases, if all transactions are single records, ACID compliance can still be counted on, for the same reason—the sheer simplicity of the transaction.

The other significant concern that would have to be addressed in using files to store application data is how the language or the underlying OS handles file locking. If either allows a file that's open for writing to be read while the write is in process or incomplete, it's just a matter of time until a read of an incomplete data file misreads the data available, then commits the bad data to the file, probably resulting in loss of data at a minimum, and perhaps breaking the entire data store in the process.

That would be bad, obviously.

Speed of access could be a concern as well, since file access is slower than access to and from data stored in memory.

That said, there are strategies that can be applied to make a local file-based data store immune to that sort of failure, provided that the data is only accessed from a single source in the code. Addressing the potential access-speed concern can also be accomplished in the same process, which would resemble the following:

• The program that uses data starts:
  • Data is read into memory from a persistent file system data store
• The program is used, and a data-access occurs:
  • Data is read from the copy in memory, and passed off to the user
• Data is altered in some fashion:
  • The alteration is noted, and the change(s) is/are committed to the file system data store before returning control to the user
• The program is shut down:
  • Before terminating, all data is checked to assure that no changes are still pending
  • If there are changes, wait for them to complete
  • If necessary, re-write all data to the file system data store