Postgres vs Firebird [closed]

You have to choose technology like RDBMS not (only) on comparing list of features but on answering questions like these:

• is it reliable enough for your needs?
• does it suit all your needs?
• what are perspectives/support/development/documentation?

For me FB is not a good choice. I can point two stories:

• I wrote constraint on table. Users add some strings to table. After a while user is trying to add one more string, but FB complains on constraint. What's wrong? This new string is surely under constraint. Problem is in a last string that was added before it! That string was added some time ago, it was wrong, and so far it is in DB, and who knows how many wrong data are now in DB. Very bad. FB implements constraints in a wrong manner.
• I wrote a Stored Procedure (SP). FB stored it in DB, FB can run it, and it works - select data as expected. No one warning. Then backup is done without errors. And only on restore FB complains that something is wrong with SP and ... what ... you have no restoreable backup copy now.

I can point two or three more but these are enough for me to say: no, FB is not my choice, it's not RDBMS, it's a toy.

And they have bad documentation. In fact there is no actual references with each release. When people ask in forums: what is a full list of functions in release XX? The standard answer is: take a list from last official Interbase release and add (remove) functions from all later releases's "release notes".

And they have strange support/development strategy. They are working on what are interesting for them, on deep technical issues, not on what are really critical or annoying for users.

I've been working with Firebird for a long time and recommend to NOT use it in any way. They have many fundamental problems that Postgres does not have. Not to say many, just say they don't still have 'alter view' command. To alter a view you must drop and recreate it and all views depending on it. This is one of many misfeatures of FB. It's not correct to compare these DB Engines at all. I've had many cases when Firebird database was corrupted even without power loss, with usual workloads, and so on. If you still deciding, don't use Firebird! If you already chose FB, you will remember my words some time later :)

I can comment on Firebird. The following changed since the first comparison:

Multi Threaded Architecture Available? Yes (super server)

Actually, Classic Server is the preferred server type for scalability. Starting from Firebird 2.5 there is also an architecture called SuperClassic. I wrote a small post on the differences: SuperServer, ClassicServer or SuperClassic?

Stores Transaction Information in same file as data? Yes (in red)

I don't see how this could be a problem to be written in red. Firebird uses careful writes to ensure the database structure is always consistent.

Temporary Tables? No

Available in Firebird 2.1. Release Notes

Rich Built in Functions? No

Firebird 2.1 also improved this. Release Notes

Multiple authentication methods(i.e. LDAP) No

While there is no LDAP support, Firebird 2.1 allows Windows authentication. Release Notes

Create user defined types? No

I'm not sure what the author means here, but Firebird has had domains forever.

Require backup/restore to compact? Yes (in red)

Arguable. Database space is reused. I find it hard to imagine the need to shrink a database in production.

Use POSIX Regular Expressions in queries? No

Firebird 2.5 supports regular expressions. Release Notes

Database Monitoring? No

Yes, Firebird 2.1 supports database monitoring via system tables. Firebird 2.5 adds support to trace facilities.
I know at least one excellent database monitoring tool for Firebird. ;)

Ability to query databases on other servers local or remote. No

Firebird 2.5 can query remote databases. Release Notes