>>I hate to give short answers, but the honest truth is that Hekaton (the in-memory optimized table feature in SQL 2014) accomplishes what you just described, as a server-based solution.
>>It's being used for heavy random reads of session based data and also for lookup tables with far greater volumes than what you've described. Also speeds up ETL processing of staging tables. So there are several scenarios where you can get anywhere from 2-10x increase in performance over regular SQL tables. It's basically an optimized row format using a separate buffer pool where you can have either hash or range indexes. Obviously, it requires a server configuration with lots of memory, but when it's indicated, it works extremely well.

Actually I'm satisfied that standard SQL Server performance is as quick, if not quicker, with this data munging on a typical SQL Server machine that has a lot more resource than your average PC. It's not an issue of database performance per se - the issue is real time user experience at the local machine. A lot of the users are encouraged to work from home and there are lots of studies saying they're more productive at home - so now you've got a VPN between your Hekaton and the user. Not sure whether you have experience of users at home, but planning means preparing for the worst not hoping for the best and you have to assume that the user's wastrel son is hogging all available bandwidth in his darkened bedroom. Which rules out real-time remote processing: a delay of a second is acceptable at the save, but if it happens every time she makes a selection, it's perceived as the age of the universe. So the dbf's advantage simply is that they are local and meet the KISS principle.