VoltDB is the latest project of Mike Stonebreaker (original founder of Postgres) aimed at very high performance OLTP. It is fairly clearly a niche product however, and not really usable in the ERP space for reasons I will discuss below.
Stonebreaker's own presentations (one example, at 11:25) suggest he is aware of this issue given his triangle framework.
In the vertices of the triangle he places NoSQL, high performance OLTP (like VoltDB) and column-oriented databases, while in the second, as lower performance generalists, what he calls the legacy databases or elephants are in the middle. The argument is that you can get a significant performance boost by specializing your systems beyond what you could when you have every system doing everything. This is a fair argument to a point, but the implementation details show that it is true only in some areas.
Stonebreaker's analysis of processing time (see above presentation, at 14:36) in traditional databases places virtually all processing time in four areas, namely buffer management, locking, thread locks/semaphores, and recovery tasks, and he suggests that in order to get high degrees of performance one must eliminate these tasks. This requires, however, rethinking how we address concurrency (the locking issues) and durability (recovery and disk-based storage). The VoltDB approach is to get rid of concurrency entirely and see durability as a network, rather than a system, property. Concurrency elimination accepted because the db is fast enough that queries can be run one at a time, and intraquery parallelism can be used instead of interquery parallelism. However, this imposes significant limitations on the database because it means that every transaction is limited to a single query. You can't do round-tripping in your transactions because this would impose locking requirements on the database.
This approach works very well for certain kinds of processing, such as consuming rapid data feeds and then feeding that information into a data warehouse at specified intervals., However one thing that is generally missing from the discussion is that the more complex the application, the more general the database solution needs to be. One solution might be to separate data entry from reporting and use multiple tools, but who wants to pull their trial balance from a different system than they enter invoices on? Since ERP systems usually tightly integrate decision support and OLTP, there isn't really room here to use specialized databases like VoltDB.
As the database market has expanded, it has created niches for products like VoltDB. These niches may indeed grow with time. However, I think it is incorrect to treat generalists as legacy, outdated approaches.
In essence VoltDB typifies what I call a specialism paradox, namely that
to perform well in a specialist niche one must give up generalist
solutions. It is true that sometimes things improve and supplant older
systems but at least as often they only do when the systems are not
vastly more complex than the ones they are replacing. For example,
Stonebreaker's comparison of high performance OLTP to the shift from
cable-operated digging excavation equipment to hydrolics misses the
fact that hydrolic systems are not that much more complex than cables
and such. There is some additional complexity, but it isn't a huge gap.
A better comparison might be comparing semi trucks to race cars and
locomotives. These are all highly engineered systems, but the basic
design considerations are very different, and specialization comes at
the cost of flexibility. You will never see race cars hauling
twenty-foot containers of furniture cross-country, and you will never
see travelling along our nation's highways to reach out-of-the-way
towns. The semi however will never pull the loads that the locomotive
can, and will never win the Indie 500...... The semi truck, however, can go fast enough, and pull the loads it needs to pull.....