One giant flat address space is not the answer.  Hardware people tend to come up with approaches like that because flat address spaces and caching are well understood hardware. It&#x27;s the same thinking that leads to &quot;storing into device registers&quot; as an approach to I&#x2F;O control, even when the interface is really packets over a serial cable as in FireWire or USB or PCI Express.<p>File systems and databases are useful abstractions, from an ease of use, security, and robustness perspective.  The challenge is to make them go faster.  Pushing the machinery behind them out to special-purpose hardware can do that.<p>The straightforward thing to do first is to to take some FPGA part and use it to implement a large key&#x2F;value store using non-volatile solid state memory. That&#x27;s been done at Stanford[1], Berkeley[2], and MIT[3], and was suggested on YC about six years ago.[4]  One could go further, and implement more of an SQL database back end.  It&#x27;s an interesting data structure problem; the optimal data structures are different when you don&#x27;t have to wait for disk rotation, but do need persistence and reliability.<p>[1] <a href="http:&#x2F;&#x2F;csl.stanford.edu&#x2F;~christos&#x2F;publications&#x2F;2014.hwkvs.nvmw.slides.pdf" rel="nofollow">http:&#x2F;&#x2F;csl.stanford.edu&#x2F;~christos&#x2F;publications&#x2F;2014.hwkvs.nv...</a>
[2] <a href="https:&#x2F;&#x2F;www.cs.berkeley.edu&#x2F;~kubitron&#x2F;courses&#x2F;cs262a-F14&#x2F;projects&#x2F;reports&#x2F;project13_report.pdf" rel="nofollow">https:&#x2F;&#x2F;www.cs.berkeley.edu&#x2F;~kubitron&#x2F;courses&#x2F;cs262a-F14&#x2F;pro...</a>
[3] <a href="https:&#x2F;&#x2F;dspace.mit.edu&#x2F;handle&#x2F;1721.1&#x2F;91829" rel="nofollow">https:&#x2F;&#x2F;dspace.mit.edu&#x2F;handle&#x2F;1721.1&#x2F;91829</a>
[4] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1628550" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1628550</a>