Perhaps I am an old dinosaur, but this article merely annoyed me.

"The key element to a memory image is using event sourcing, which essentially means that every change to the application's state is captured in an event which is logged into a persistent store."

That is a key element of a database. It's called a logical log.

"Furthermore it means that you can rebuild the full application state by replaying these events."

Yup, logical log.

"Using a memory image allows you to get high performance, since everything is being done in-memory with no IO or remote calls to database systems. "

This is _exactly_ what sophisticated old-school databases do. You can have them require to write to the DB on commit, or just to memory, and have a thread take care of IO in the background.

"Databases also provide transactional concurrency as well as persistence, so you have to figure out what you are going to do about concurrency."

Righty-ho.

"Another, rather obvious, limitation is that you have to have more memory than data you need to keep in it. As memory sizes steadily increase, that's becoming much less of a limitation than it used to be."

So why not store your old-school DB in memory?

I can understand the argument that you don't want to lock into a big DB vendor's license path, but the technical arguments here look distinctly weak to me.

Maybe old-fashioned DBs are hipper than people think?