Devart Forums

This version seems to solve the slowdown issue I had with 6.3.12 and FB3.
On a local test the only speed bottleneck was my Network speed, not the db (Firebird-3.0.1.32540).

Thank you for being interested in our products. We are always working on performance improvements for our products to meet our users' requirements.

uhmmm. we had performance issues with FB3 and UNIDAC? This would be the reason why Firebird 3 was slower than many other DB's.

I done some performance tests to identify the DB I should be using to replace my Oracle XE (which was heading to it's storage limitation) in an internal project. The result in terms of speed for different tasks (connect, insert, select, update) and in terms of speed we have:
1) MySQL was the fastest
2) Oracle XE was surprisingly the second
3) PostgreSQL
4) Firebird
Used latest version for all datbases

Some data:
Connect to PostgreSQL: 319.1402 ms
Connect to MySQL: 28.8735 ms
Connect to Firebird: 306.1888 ms
Connect to Oracle XE: 62.6548 ms
Connect to Oracle Standard: 34.5029 ms

Select MAX(ID) PostgreSQL: 99.235 ms
Select MAX(ID) MySQL: 1.7234 ms
Select MAX(ID) Firebird: 9.7763 ms
Select MAX(ID) Oracle XE: 0.9246 ms
PostgreSQL was quite slower and I believe in each DB the performance could be much better after some tuning.

Insert 10k records - PostgreSQL: 1325.5662 ms
Insert 10k records - MySQL: 1232.9713 ms
Insert 10k records - Firebird: 8674.6675 ms
Insert 10k records - Oracle: 1655.81 ms

PS: Note it was a simple test where all tables in all databases were the same, some tables with and without index, etc.

For my simple usage of storing some statistics data I would say MySQL is really the best option

andrefm wrote:uhmmm. we had performance issues with FB3 and UNIDAC? This would be the reason why Firebird 3 was slower than many other DB's.

FB3 needs batch updates and performance isn't what it should be yet.

In this last stress test it wrote about 250k records, then processed them via Stored Procedure and stored another 750k records. All in good speed when compared to SQL-Server.
However extracting a full batch of 1.3 Million records took 6x longer than SQL-Server this time and by that I mean this FB Snapshot.

This was using the Embedded engine on a local SSD. An Azure test against an FB Server on an SSD was 12% slower than SQL-Server on input and output was still 6x slower. These numbers have jumped dramatically depending on UniDAC and the FB Snapshot used.

It is not quite correct to compare performance when working with different DBMSs, since many factors affect performance: the architecture and configuration of the DBMS, processors architecture, network organization (LAN/WAN) etc.
You can increase performance of working with the database using Batch Operations. See more details about using Batch Operations in our products in our blog:http://blog.devart.com/using-batch-oper ... nents.html

andrefm wrote: For my simple usage of storing some statistics data I would say MySQL is really the best option

MySQL with MyISAM or InnoDB?