MySQL:
Oracle:
DB2:
Informix:
SAP/Sybase:
PostgreSQL:
(Wow! PostgreSQL is just really fast.)
SQLite:
(Of course, SQLite is incredibly fast.)
Test Environment
To perform these tests, I configured a Fedora Linux QEMU VM to run SQL Relay on one VM host, and various CentOS VMs to run the various databases on a separate VM host. All VMs had 1 CPU and about 2Gb of RAM. They're connected through a 1G switch.
The DB VMs ran modern versions of all databases, in their default configurations, without any performance tweaks.
I built Rudiments and SQL Relay without any optimizations, using just ./configure
The SQL Relay configurations were all pretty standard too. For example, the Oracle configuration was something like:
<instance id="oracletest" dbase="oracle>
<listeners>
<listener port="9000" socket="/tmp/test.socket"/>
</listeners>
<auths>
<auth module="sqlrclient_userlist">
<user user="testuser" password="testpassword"/>
</auth>
</auths>
<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.
