Current SQL Relay Benchmarks

(as of 12/22/2016 using SQL Relay 1.0.0)

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.