Why Firebird is cool?

I've seen a lot of discussions between developers, students, administrators and other geeks regarding "what is cool and what is not". Definitely such talks are good with good beer in hand (like Czech's Velvet one :)), and they are very similar to any other "holy war" regarding software, cars, movies, etc.

Though such discussions are pretty common and may seem to be useless (especially without beer :), they actually represent the powerful marketing activity, the highest dream of every marketing manager - "word of mouth". Don’t omit the chance to tell someone about Firebird – it really helps, believe me.

So I decided to consider here 3 main talking points to help all of Firebird fans, developers and adopters to spread the word in the right and effective way:

1) Firebird is universal. By universal I mean not only the really wide range of supported range of platforms with (very important) 100% compatibility and easy one-step migration, but also the ability of Firebird to perform all types of database tasks: it can be used in ERP, CRM, billing, reporting/BI, web-site and other applications.

2) Firebird is flexible. Multi-generation architecture, suitable triggers and stored procedures allow developer to develop applications and achieve business goals in very fast way. Deployment is also very easy: small deployment packages without registration/activation can be supplied "as is" or built-in to enable silent installation, with choice of 4 architectures to bundle with your application: Embedded, SuperServer, Classic and SuperClassic (2.5).
Also flexibility means that you can use Firebird in almost all development environments and tools: .NET, Delphi, Java, PHP and dozens of less known languages.

3) And, the most important, Firebird is good enough. I like the comparison of Firebird with well-priced Japanese car: good-looking, comfortable, safe, with low fuel consumption and reliable. Definitely you cannot put 250 tons of rocks into its trunk, and you can't outrun flying Boeing... But do you really need it or ever wanted to do it? The same thing is about Firebird: it is enough for the majority of business tasks and fits 99% needs of enterprises in SMB segment (SMB states for Small and Medium Business, i.e., for people who count on real values and live in real world without personal jets).
Firebird is equipped very well to handle business, and it remains compact, fast and transparent for developers.

Of course, during the holy wars there are always objections and attempts to raise old dead myths from graves:

1) Firebird is for small databases and it cannot handle large database. This is really funny myth, especially after our test with 1Tb database and many examples of real-world multi-gigabyte databases. But there are one thing to be highlighted every time when you see this stupid statements: the density of stored data. It's not well-known fact that Firebird keeps data in compressed way, approximately 2 times more than MS SQL and Oracle. So 10Gb Firebird database actually will be ~18-20Gb database in MSSQL or Oracle (if someone would like to check it, I will be glad to publish the results here and everywhere).

2) Firebird is a slow database. The flexibility of Firebird has the other side: it forgives developers much more ugly things than other databases. Firebird keeps working when Oracle will say something regarding "rollback segments", it keeps working when lucky MS SQL administrators buy the second set of licenses and 30k hardware to deploy reports-only instance.
Definitely Firebird has limitations of self-tuning and out-of-box performance endurance. Guys, even the best Japanese cars can be broken, especially without right maintenance in heavy conditions and while driving by inexperienced driver.

3) Firebird is not reliable because it has no transactional log. This is as far from truth as statements that all Russians love vodka and all Americans love Kim Bassinger.
The concept of reliability cannot be based only at one technical feature. The right approach to provide stable work of overall IT system, reduce risks of outages and corruptions is to develop and prepare whole infrastructure to be ready for emergency situation and have in place realistic recovery plan (btw, that's we are doing in IBSurgeon :)).

When next time you'll hear this bollocks regarding absence of transaction log, just ask your opponent: "Do you have recovery plan for your full-blown 5k-per-CPU powerful database system? NO? So keep your fingers crossed, you'll need it sooner or later".

I think this is a bit more for three-beers-talk, but I hope it helps. :)


  1. Regarding myth no 1., I recently did the a comparison test and here are my results for creating the same DB structure for 3 different RDBMS:

    FB 2.1.3 - ~32 MB
    SQL Server 2005 Express - ~27 MB
    PostgreSQL 8.2 - ~62 MB

    Actually, I am evaluating FB and PG for new project, but I also tested SqlServer, which also showed best performance with large margin, but this might also depend on ADO.NET providers for these systems.

  2. 32Mb is too tiny size to compare. Actually there are more metadata than data. Also data density depends on type of data you store and their average length. For example, with BLOBs of size slightly less than page size, Firebird will use much more space due to fragmentation issues.

    And - with MSSQL you are not only tied to Windows, but also restricted with 4Gb in size, and after that you know what happens - 5k$ for standard edition per instance and so on :)

  3. I am aware of that and I understand that this is not a production DB. However, it contains couple of hundred thousand records (2 tables only with a few columns each, no BLOBs, extremely simple model). Therefore, I don't think that metadata should influence the size that much (same DB, prior to inserting records is ~2 MB).

    Anyway, I was more concerned with speed than size, and FB proved more or less equal to PG, while having much lower disk footprint. I will retest with larger data set and post the results, although, IMO, it is not possible to create a fully impartial test for different DBs.

    MSSQL was never an option for me, but I wanted to check how it compares with best open source DBs (FB and PG, MySQL is not even close), and honestly, it was much better than I expected. Still, I wouldn't choose it due to other drawbacks/limitations. Actually, I have used FB exclusively in previous 3 projects (from 1.5 onwards), but I expect much higher load and more data in new app, so I wanted to compare it to PG. It is still a tie performance-wise, and I guess that deal-breaker will be external tools - replication, backup, etc...

  4. Currently we are using Firebird 2.1.3 with our software. Our operational databases size is 4 GB. We have more that 100 such databases in different offices. The central archive database size is 80 GB. The Firebird is performing VERY WELL. It's fast and stable. We have been using Firebird since year 2000. I am recommending it for heavy duty work.

    Excuse me for my bad English.