I have been following this thread since it started.

I am finding it very interesting seeing the comments regarding both Firebird and PostgreSQL.  I thought I would add my 2-cents in.

When reviewing the use of a new database engine, I believe taking a more general view of any database engine's capabilities will do more for assessing its adoption than many of the specifics mentioned.

As I have worked on many large-scale, enterprise projects in my career, I have found that any of the major database engines, whether they be commercial or Open Source, are all highly capable.  That being said, out all of them, I have found Microsoft's SQL Server to be the most capable and the easiest to use for all of the development requirements I have had to work with.

This would be followed by Sybase's ASE enterprise engine as in many cases it was quite similar in many ways to that of Microsoft's SQL Server.

I also worked with Oracle and found this engine to be extraordinarily powerful.  As to its ability to save stored procedures with errors, this was a feature that allowed developers to maintain their PL-SQL code in the database's repository instead of having to save it locally until it was entirely clean and working to the specified requirements.

No doubt that Oracle was a bear to learn but once learned you had a wide variety of capabilities (ie: array processing in PL-SQL) that few other database engines at the time had.

Unfortunately, Oracle was designed for high-end development with very large databases.  As a result, it was very expensive and often employed in heavy duty database arenas.  Those organizations that did not actually require Oracle but were using it anyway only did so for its status since they were losing a lot of monies that were unnecessarily to support the infrasrtucture that was required to maintain Oracle.

For its capabilities, the current versions of Firebird are around the level of Microsoft's SQL Server 2005, which by the way was a very capable engine in its own right.  And it doesn't have many of the advanced features you will find in the databases with much larger communities.  However, that being said, many such features are quite esoteric and will never be used on a regular basis for most development endeavors.

Between standard Firebird and the advanced form that HQBird offers, this engine probably provides capabilities for around 85% to 90% of all database development requirements both large and small.  The fact that it may not provide one capability or another should not dissuade anyone from considering its use given that practically in all cases workarounds to such deficiencies can be developed.

PostgreSQL on the other hand was extended from its origins in the commercial Ingres database engine to provide very powerful capabilities that now mirror those of Oracle.  In fact, the EnterpriseDB company uses PostgreSQL as the foundation for its Advanced PostgreSQL Server, which provided all of the Oracle capabilities with similar speed and power and at far lower costs.

PostgreSQL on its own however, can handle just about any major enterprise level development endeavor and like Oracle, provides a rich set of capabilities in its own PG-SQL language.

To be honest, I actually found the Firebird PSQL language to be the most difficult to learn: not because of any inherent difficulties with the language itself but instead with the poor error reporting from the compilation of either inline SQL or its stored procedures and functions. This made deducing the actual cause for an error very difficult.  Practically every error I had to deal with was always reported as a missing semi-colon at the end of the SQL code or something to that effect.

PostgreSQL's PG-SQL language does have its own idiosyncrasies but once mastered it is quite powerful and very extensive.  I believe the reference manual for PG-SQL is over 2000 pages.

As a result of this set of viewpoints then, if one is going to endeavor to implement very heavy database requirements that could span multiple databases of very large sizes, as capable as Firebird may be, I would instead prefer to work with PostgreSQL.

However, if the requirements are going to be varied across numerous departmental level forms of development (which even today the majority of database development is centered around) and even larger, there is no reason not to consider Firebird as it is a very capable engine.

Looking at the details of which database can offer what or what each may not offer will only add to the confusion regarding such a decision.  The basic premises are the known power and general capabilities of an engine for those development environments that require high levels of database support for high concurrency applications and the ability of such an engine to be clustered across multiple servers.  For most such development, Firebird should do just fine but there are areas that PostgreSQL will be far better suited for the tasks.  As a result, it is the complexity of the database development endeavor that should be considered as the primary concern and not the individual features of any one engine.

Just my 2-cents...

Steve Naidamast

Sr. Software Engineer