Gemfire can ingest large amounts of data extremely quickly, even when the data is coming from multiple sources, Cucchi said.
"If you have to handle a 1,000 requests a second, you insert the in memory layer of Gemfire and it effectively offloads the real-time requirements for the application," Cucchi said.
This technology could be used, for instance, by a wireless telecommunication provider. Gemfire could be used to ensure all the calls it handles at any moment can be routed through the best network path at that time, Cucchi said.
Not everyone is convinced that special in-memory databases are needed. Many others have taken the approach of running an in-memory caching layer above the database, to serve the most requested fields.
"People have been doing in-memory databases for years, where you have terabytes of RAM across many machines, all fronting MySQL" said Bryan Cantrill, software engineer at the Joyent cloud service. Cantrill points to the growing popularity of Memcache, which is being widely used as a front end for relational databases.
What should an organization do if the amount of material it has on hand exceeds the available working memory?
Many in-memory technologies, such as Microsoft's and IBM's Blu are actually hybrids, in that they can still store some material on disk, and only keep the most frequently consulted data in working memory.
Like other in-memory systems, SQL Server 2014 has a few tricks to preserve data should the power go out, causing data to disappear from the volatile RAM. The tables are never written back to disk, but any changes are written to data logs. Should the power go out, the database can rewrite the lost data using the logs.
SQL Server 2014 comes with diagnostic technologies that can examine the user's databases and suggest the tables that should be moved to memory, based on how often they are consulted. "Just move the tables that are hot into memory. That will allow you to get big performance gains without having to buy new hardware," Kelly said.
No changes are needed at the application layer, which still sees the same database interface, Kelly said.
Researchers are experimenting with other approaches as well. Stonebraker is investigating an approach called reverse caching. In traditional caching, the most frequently consulted data is to keep live in-memory. With reverse caching, only the data that is rarely consulted is written to disk.
"We have compared caching with anti-caching with a prototype at the [Massachusetts Institute of Technology] and anti-caching is a way better idea than caching," Stonebraker said.
Part of the problem with caching is that when a caching system, such as Memcache pulls data into memory from disk, it pulls in the entire block of data on disk, which usually includes additional records. So the approach makes for inefficient use of memory. In contrast, a memory-first approach only writes to disk those specific entries that are rarely consulted.
Whether through an enterprise-ready in-memory database system, or an open-source caching layer, the organization is now able to serve its customers and its business managers much more quickly.