MySQL:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjC5T4H8DOywRyyT-dQcPueF8A46W03WAiwncnvauy8M47SfUA2v3_mdSwbL4L1WZdGLNpltf-LW5gY7DP0zDYikbgM-TLKTzbpaiV0jKEIPPNquVpQLimclZTodV6sVU72IHxSbjOnct5H/s1600/mysql-bench.png)
Oracle:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidPynrtfLZ3NdbOxleRGTVTSBco4pjGNoKNa4tLV1-AEVm1NnMLRqNfryeil-4tPeEGCLlFkzWLyjnnEuQtUXAWy8Ipt6yJ2_scd7e4B2rl-inpALDChx4a5zSIJ2x4R6rpYJ2819L20WR/s1600/oracle-bench.png)
DB2:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0fVkeTnDr472kQB_U50JJ7Gvz2k0QybaAikBum9P3nB5JPVI4G35SO5zQWF3DbrTS5CcjGLmoWCpw_2djoc6Df7hFonPn6N5E_paSb77ANXncTE8CwVFmd_7c_WXPGlyQhy81vp1vMht8/s1600/db2-bench.png)
Informix:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAfJzPX77SiT-4-XGPyEYs9ZcxY4_JZ7EUooKEA8AGIv8GXnyRaIIbdQh3zvimxUSahBKNl7vbqTF5426nZiFC8I91gLMPG1A4ljxhMekwhCRjSoLGVmdK9QzdpyQYe6RuSx8c2t5cLQ8a/s1600/informix-bench.png)
SAP/Sybase:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgAmoP7Y2nix8EZ3R7Jeijar5_3eWeOgKESw8g6YAucJ8OJ2kG1Z2BNkOyU5dYEgdZy0-lCo7igiiTvSRqGqQ103u0AGco5ZcrTmFSjPfzQ3lNCZ8r7Ip7ImXEfIMoFtqemxOWB-dnouVPy/s1600/sap-bench.png)
PostgreSQL:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMMgDf3E1R7CgbzRarxv-mYr5y7z62spGSZpW7ALkFpjt9T3bqJGaJ2q1B-5_7z9dBJplnZfcUdHahFrFWg_pSOCqJGk7eP1319Q6fx7NX8DsWpwfNAEErYZmeu9xzoeF4UNpAKUUFKmzv/s1600/postgresql-bench.png)
(Wow! PostgreSQL is just really fast.)
SQLite:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhX0BOQpreEwPPnzdbfEB-56Cd3GcqDrJI94eIq9jxYzCmeXDO0JNYgAkxQQuFB60NT68dxQWAhsoJrK7ShJTj7QRKLs_Zo03ujgJ-jCSgq2rn0MZZ_ZRe2nKsxmB1OH5ZV5P1BLxpJIozd/s1600/sqlite-bench.png)
(Of course, SQLite is incredibly fast.)
FreeTDS (against MS SQL Server):
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsnLGd7h3eMlXf96Ka4Y2jhqj9S77o2EHkYlP_TvHvVQF627cb-ZjCXh7SGTcebQzfMd-Q6YDkEV1Z5FyAQfX7InPHhJOjYMjnab5R7Ggs_50I3fW2av1jRPcwhuesAmtc4Txe4nim2aSG/s1600/freetds-bench.png)
(??? Is SQL Server limiting throughput?)
Test Environment
To perform these tests, I configured 2 Fedora Linux VMware VM's. One for the databases and one to run SQL Relay. Both VM's had 1 CPU. The database VM had 2Gb of RAM. The SQL Relay VM had 512MB.
The DB VM ran modern versions of all databases, in their default configurations, without any performance tweaks.
I built Rudiments and SQL Relay without debug and with -O3 optimizations like: CPPFLAGS="-O3" ./configure
The SQL Relay configurations were all pretty standard too. For example, the Oracle configuration was something like:
<instance id="oracletest" port="9000" socket="/tmp/test.socket" dbase="oracle"> <users> <user user="test" password="test"/> </users> <connections> <connection string="user=...;password=...;oracle_sid=..."/> </connections> </instance>
For the PostgreSQL tests I disabled typemangling.
The actual tests were performed by the sqlr-bench program which can be found in the test/bench directory of the SQL Relay distribution. It must be run from that directory. I ran it with default parameters. There's a benchall.sh script there too, which starts and stops the appropriate SQL Relay instances and runs sqlr-bench. I actually used that script rather than running the tests individually.
But my app needs to run thousands of queries per second...The sqlr-bench program measures the raw throughput of a single-process/single-thread. This provides a good low-level basis for comparison, and makes profiling easy. It doesn't (currently) measure the maximum throughput that SQL Relay or the database can sustain from a multi-process/multi-thread app distributed over a pool of application server nodes. In an environment like that, substantially larger numbers of queries-per-second would be achievable via SQL Relay, or directly against the database.