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. :)