REAL SQL Server vs. OpenBase SQL
At the 2007 REAL World Conference held by REAL Software there was mention of how their REAL SQL Server performed compared to OpenBase SQL. OpenBase was not invited to comment or review the tests or results in any way prior to the announcements at REAL World. We have no idea what their testing basis was, what the criteria were, nor do we have access to the actual tests they used. However, we would like to offer our own analysis.
REAL SQL Server is based on SQLite, a single-user database engine. SQLite is great for some uses, but SQLite's own website warns that it should not be used for applications requiring client-server access or high concurrency, and that corrupt files can be the result if misused. It also lacks the data-redundancy of OpenBase SQL. So while it may be a capable single-user database, it does not deliver the multi-user access or fault-tolerance required for business critical applications.
Every multi-user database must be able to coordinate effectively between a variety of requests from different database clients. Concurrency issues, in which changes to one table block selects/reads from another, with resulting bottle-necks in performance are inevitably created. So while fetch performance can be important, there are many inter-related factors which also need to be looked at. This is one reason why SQLite's own pages state that it may be inadequate for high concurrency uses.
We have tried our own test bed with REAL SQL Server and compared it to OpenBase SQL in several areas. We have also been in touch with the developer of REAL SQL Server about our results and shared our testing code and methodology with them.
The first thing we found is that there is a big difference between single and multi-user results. Inserting 100,000 records using the multi-user version of REAL SQL Server took between 10 and 100 times longer than the SQLite engine running in single-user mode. The single-user SQLite version is faster than OpenBase SQL; however, the REAL SQL Server version is significantly slower, even without the mechanisms to handle fault-tolerance.
Then we tested multi-user access on REAL SQL Server. We found that with two database clients (or two threads) we frequently got errors as clients blocked one another from inserting. We also found that transactions would fail when they exceeded the server's maximum lock time. Getting two threads to insert 100,000 rows simply does not seem feasible. With some experimentation, we found that transactions involving over 50 records consistently failed.
We tried all of these tests with OpenBase SQL using nearly identical REALbasic code. All tests on OpenBase SQL completed accurately, without errors and in significantly less time than REAL SQL Server.
We advocate using the right tool. We want to stress that SQLite is a fine product for what it was designed to do. The SQLite website states, "In order to achieve simplicity, SQLite has had to sacrifice other characteristics that some people find useful, such as high concurrency, fine-grained access control...." http://sqlite.org/whentouse.html
OpenBase SQL delivers a solution that protects data, minimizes maintenance, and, ultimately, lowers the total cost of running businesses. Fault-tolerant features are built-in to keep database data safe from file corruption.
OpenBase SQL balances performance with a variety of real-world needs, making it an effective solution for small to medium sized businesses.