I've designed large data stores (sitting on about $3-10M of hardware). The challenges that @jharonfe brought up are valid, but I don't feel they're the most interesting challenges in your case (20 stocks, L1).
For example, there's no reason why your system, even it's very naively designed and unoptimized, should fall behind on 20 symbols.
You also mentioned missing data - you might have seen that issue brought up by some of the older, publicly available texts on how to store market data. Bear in mind these were written years ago - that's not really an issue nowadays when the exchange networks are highly overprovisioned.
Here's a few that are worth thinking about:
- Non-homogenous trade sessions. For example, IBM still trades today but there was a period when its ticker stopped trading because of anti-trust investigations. People who design their data storage to handle expirations (e.g. options) tend to think about these issues more, but equities have their own peculiarities. Also, if your equities originate from different exchanges, different markets have different holiday schedules.
- Survivorship bias. This is a pretty obvious one. If you know after-the-fact today that you cannot trade XYZ and that's left out from your symbol universe, yet you were collecting data for XYZ 1 year ago, you're incurring survivorship bias by allowing your backtesting engine to be aware of this and be unable to backtest on XYZ 1 year ago or exclude XYZ from your search universe 1 year ago. The reason this gets challenging is that it's easy to describe but it involves interfacing several pieces of software, which people tend to avoid in the first pass of architecting their platform.
- Trade breaks. In certain venues, you can get info after-the-print that a trade has become nullified. This poses issues in deciding how to handle the fill in your backtest but people often ignore this type of edge case in their first pass design.
- Lossiness and transactional history. As you can see in a common theme between my above 3 points, the solution is often just to ignore the problem and worry about it later. This is fine so long as you don't lose the data when you come around to deal with the problem. This is one of the reasons why using a DBMS can be superior to a flat store, because many DBMSes are transactional and have a commit history.
- Corporate actions. Equities go through mergers and acquisitions, stock splits etc.