I do think an OLTP appliance is feasible,
think about navigating a b-tree to an index search.
assume everything is in memory
1. start with a memory access for the index root level, find the row for the next level.
2. issue a memory access for the 2nd level,
wait for the off-die memory latency (60ns Opteron direct to memory, or 90-120ns for a two-hop, CPU to CPU to memory and back)
3. and so on.
Depending on the database page organization, find a row in a page is just as stupid as far as CPU-memory access is concerned. In SQL Server, after the page header, data rows are filled in from the beginning. Row headers are filled in from the end. I think Oracle is the reverse. Either way, it really stupid.
1. issue a memory read for the row header,
2. when the read returns, use that to issue the read for row,
3. then navigate through all the variable length offsets to get the column you want.
I have even mentioned locks.

My thinking is a OLTP appliance would have a CPU die, with DRAM die stacked on top, as described by Intel. This has very low latency and massive bandwidth. This memory would be used for locks or data structures requiring very fast turn around. Possibly use SRAM for what should be main memory. DRAM should be used a data cache.

I am thinking there might be possibilities with the MetaRAM device that makes 2-4 DRAM chips look like a single chip, allowing 8 and 16GB DIMMs with 1Gb chips.
Well, if one is going to have logic so close to the DRAM, why not have some additional protocols.
Instead of:
1. CPU fetch this address from memory
2. use contents to issue next fetch.
New protocol:
1. CPU issues an address to the memory side logic.
2. MLogic uses the content of the address from CPU as the actual address contents desired.
It would have to be more sophisticated, but hey, this a blog