Best Performance Databases From Not-so-far Future (published By Parts) MMDBs, executable SQLs and all-all-all

Part ISome time ago I was acquainted with one very fast bussiness-critical web-server application, and I became very interested, - how does this site work, outperforming fastest GUI applications?And what was told to me.Design has to met with very tight requirements for performance of system: simply to be the most powerful solution by performance, given that it should run on ordinar server equipment.The guys who get this proposal owned some parts of this technology, so they brought up their components, and voila -solution is ready! They used their own ready web-server engine, and it was entirely been written using C++/STL and keeps all the data in memory.For extendability it used plugins mechanism in fact, it was one resembling something like CGI for plugins.Not only the web-server, which is not, may be much surprisingly, been written using C++, but also its database system, was designed for better performance using C++ and keeps all its data, as I said, in RAM.That's all good, but now I'm thinking, what if...It was - and is  - a system designed for best possible performance, but it yet has one weak point.  - People, more exactly, Programmer, who designed and developed the entire system, was used C++ for it, and he has written every one of dozens of SQL requests by hands, using STL containers of C++. And when at some time he will express the desire and leave the project, he will leave it in unmaintainable state: system, supported by not so skilly personnel couldn't be possible to answer customer (frequently growing) needs, and would be in the best case only keeped in running in as-was state...What was the main problem of it?I think that it wasn't used wide spread (mainstream) components to build a such bright and very fascinating technology, reinventing the wheel, saying so. Moreover, most of available tecnologies are open source, if not all. The technology stack of bricks could be:1. Database: any database which keeps its data in and operates on RAM, i.e. MMDB, In-memory database,    RAM nowadays becames so cheap, and people not yet accounted that fact and not yet widely using such DBsThese databases have certailny their SQL too, but that is not the best performance Database case, we should use compiled to native executable code database.2. Bussiness-logic level language: There are available native code compilers for most scripting languages, so it could be written on PHP, for example, or PERL, or Python, and compiled to executable, which runs ten times faster.3. Fast, lightweigh and very stable Web-server, written preferrably on C/C++4. And the last brick to close the circle should be the SQL-to-native code compiler, the thinner place for now.To be continued...

Hi,We have created an open source benchmark project at https://sourceforge.net/projects/benchmark/ that includes some of the most widespread databases:- STSdb- Oracle Berkeley DB- Perst- MySQL (server)- MS SQL Server CE- Access- HamsterDB- SQLite- Db4objects- Firebird- H2.We accept proposals from Db4objects community to improve test results.