Unfortunately, many people still have wrong perception of Firebird as a “free InterBase”. InterBase and Firebird were very close in terms of features and low-level compatibility during versions 1.0 and 6.5, but these versions are gone long time ago (I think there are some people who use Firebird 1.0.x on legacy systems, but I doubt there are much people at InterBase 6.5).
Another obvious reason why people still consider Firebird and InterBase as closely related to each other is that producers of developer’s tools and libraries traditionally support both servers, so it may look similar to create applications for Firebird and InterBase (or even try to create the single code work for both), though this is quite limited point of view, as we will see. We are at IBSurgeon also provide recover services and tools both for Firebird and InterBase, but, as you will see later, it does not mean that databases have identical internal structure or maintenance approach.
And, of course, lack of information regarding differences is also the reason of confusion. In this series of blog posts (I hope, afterwards we will put all pieces into the single article) we‘ll consider the most important differences between Firebird and InterBase.
We’ll start with 32-bit support and 64-bit support and implementation limits in Firebird and InterBase, then continue with architectural differences, devote some time for garbage collection implementations (including indices), compare incremental backups and logs approaches, look at maintenance differences (including recovery and anti-corruption techniques), then discover differences in transactions’ processing and finish with total cost of ownership. And probably there will be more topics between these milestones – the appetite comes with eating. So let’s go!
32bit and 64 bit support
We'll start with very basic differences: 32- and 64-bit support. As you know, Firebird fully supports 32-bit and 64-bit versions of Windows, Mac OS X and Linux, and InterBase works at 64-bit operation system only in compatibility mode.
Someone who knows that the main overhead in database management system lays in I/O operations can ask a very reasonable question: "What is the real benefit from 64 bit support? Is it a big deal?"
Actually it is big. The main advantage of 64-bit systems against 32-bit is memory usage limit. 64-bit systems allow server to use much more RAM.
Look at Microsoft knowledge base item with technical information regarding RAM limits:
and good FAQ regarding 64-bit systems here here:
Here is an excerpt:
|Maximum RAM*||Maximum CPUs*|
|Windows XP Professional||4 GB||128 GB||2||2|
|Windows Server 2003 Standard Edition||4 GB||32 GB||4||4|
|Windows Server 2003 Enterprise Edition||32/64 GB**||1 TB||8||8|
|Windows Server 2003 Database Edition||64/128 GB**||1 TB||32||64|
(Many people do not like Microsoft but it's hard to deny their technical expertise and the fact that big % of Firebird installations are at Windows now.
I did not find the same information regarding Linux/Mac OS X but I'll be glad to insert link & info here if someone point me to it).
RAM chips becomes cheaper and cheaper. I remember that in 1999 I saw computer with 64Mb of RAM and that was cool (and in 1994 4GB RAM was just amazing! etc, etc), and now 48Gb RAM is affordable not only for NASA or oil companies.
So if you can put more RAM at server there is no reason to do not insert new chips... except that your software will not use it.
As you probably know recently we did test with 1 Terabyte Firebird database (http://www.ibsurgeon.com/articles/item104) where referred to several real-world Firebird installations which will reach comparable sizes soon.
Since InterBase does not support 64-bit architecture it has no chance to support such big databases and remains database for small and medium size databases.
And it is in even more deep... trap than you can imagine - because since version 7.0 InterBase has the only architecture to serve multiple connections: it's SuperServer.
SuperServer is the single process which maintain multiple threads to serve connected users. 32bit architecture limits RAM size available for InterBase with 2Gb (there is a possibility to use 3Gb at Windows if application will be compiled with special option and if 4-gigabyte tuning (4GT) feature is on.
From practical point of view this approach limits the number of database page buffers which can used by InterBase. For example, if you would set database page size to 16384 and set page buffers to 100 000, InterBase process will occupy 1.5Gb of memory for buffers. The limit is 131072 page buffers with size 16384 bytes (actually gfix will not allow to set more than 131071 buffers to avoid erroneous situation).
So it seems that we have moved to the discussion of Limits. We'll devote next part to the limits of Firebird and InterBase and their differences.
To be continued...