MySQL:
Oracle:
DB2:
Informix:
SAP/Sybase:
PostgreSQL:
(Wow! PostgreSQL is just really fast.)
SQLite:
(Of course, SQLite is incredibly fast.)
FreeTDS (against MS SQL Server):
(??? 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.
