Why not use firebird?

Question

There have been recommendations to use Firebird as a enterprise alternative to Oracle, MSSQL, MySQL, PostGre.

I'm planning to move some our SQL Server databases to viable alternatives and I'm interested in Firebird as a possibility (alongside Postgres and MySQL).

Question

• Why shouldn't I use Firebird?
• What problems do you usually encounter while using Firebird?

NB: Please include version number.

Answer 1

No Scalable (SMP/multi-core friendly) engine with the shared page cache

Actually we have this : Firebird ClassicServer or SuperServer

You can also check Firebird tracker

Nothing is perfect :P

Firebird 2.1

Answer 2

Unrestorable backups, for example.

Answer 3

The Firebird website makes it difficult to find technical information quickly. There's no search feature, for example.

The documentation itself was clearly designed for PDF and print media, not the web, which makes it very hard to navigate from one section to another.

You'll also find that much of the documentation assumes you're familiar with older versions of the Interbase database.

The quantity and quality of technical information is an important consideration for enterprise databases. More popular or more mainstream databases have larger communities and tend to have better technical resources.

I'm a big fan of Firebird, though. It's been rock-solid for us as an embedded database. It's been evangelized among us developers, but there just hasn't been the same push to reach the DBA community.

Answer 4

There are many obstacles to adopting Firebird in an enterprisey environment:

• Sysadmins / DBAs aren't familiar with it, and therefore may ban it outright. Admittedly, this is a chicken-and-egg problem.
• Dearth of up-to-date and searchable technical documentation.
• Lack of proper auditing support. Fixed in Firebird 2.5.
• Lack of DDL triggers. Fixed in Firebird 2.5.
• Deficient authorization support.
• Narrow range of built-in functions (although this has improved recently). Developers frequently need to develop user-defined functions (UDFs), which must be in a native dll installed in the database server's installation tree. This complicates deployment.
• Incomplete SQL language support for BLOBs.
• No built-in support for bulk data import/export (it's possible, but convoluted).
• It's needlessly complicated to deploy databases remotely.
• There is no support for discovery of database servers, nor for instances within a server, nor for databases within an instance.

The above is as of version 2.1

Answer 5

Sometimes the corporate environment doesn't look at open source with good eyes, usually because of "corporate culture". I know this is changing, but we still have some companies with this mentality.

Fact is I haven't seen many corporations (at least in the market we usually work) using Firebird. But I have seen a lot using MySQL and PostreSQL. This doesn't mean it's bad, but it's a fact people consider: When you see that "nobody" uses something, specially in the corporate world, you usually don't trust it.

What you should be asking is: what advantages are people saying to you to use Firebird? Do the other options (MySQL, PostgreSQL) have it? If so, choose which one is more used and have better documentation and user base.

EDIT: Out of curiosity, why is my answer with -1? If an answer is off-topic or not useful, I understand the negative comment even without justification, but why set simply set -1, specially when the last paragraph says almost the same as the most voted question in this thread?

Answer 6

Right now, all I can find are these problems:

• Firebird doesn't support many indices (unlike PostgreSQL)

• Firebird doesn't support many partitioning methods (unlike PostgreSQL and MySQL).

• Firebird doesn't integrate with LDAP (for Windows Active Directory and other SSO/central management systems), unlike PostgreSQL.

These are from Wikipedia's Comparison of RDBMS's:

http://en.wikipedia.org/wiki/Comparison%5Fof%5Frelational%5Fdatabase%5Fmanagement%5Fsystems

I looked into Firebird for one of its strongly hyped releases in case it was an idea to replace PostgreSQL or MySQL with it, but found fundamental problems that made it sounds like a toy by comparison. Unfortunately I can't remember exactly what these were now, and it was only documented in the intranet of a company I used to work for, to which I no longer have access. Could be that I got it wrong back then, or that the problems are fixed. However, my advice would be to do a LOT of research before banking on Firebird.

Answer 7

I've been working with Firebird to develop some desktop and small network applications since 2002, I've decided it over MSSql server and Postgres because it can be installed without supervision (I give my application's installer and the user just clic "next" until it is done).

Recently I worked with Postgres to develop an intranet application with some friends, the main difference I can tell is that Postgres seems more mature, for instance it has its own IDEs (PgAdmin for local and PHPPgAdmin for internet). Its Server Language (PL/pgSQL) is nicer than Firebird's, one thing I like about postgres is that it is more comfortable, assume you have a table CarTable( IDCAR bigint, MODEL varchar(50) ); in Postgres in a Stored Procedure you may say:

declare theCar CarTable%ROWTYPE;

theCar.IDCAR = 5; theCar.MODEL = "xxxx";
select * into theCar from CarTable;

in Firebird you have to:

declare theCarIDCAR as bigint;
declare theCarMODEL as varchar(50);

theCarIDCAR = 5; theCarMODEL = "xxxx";
select IDCAR, MODEL from CarTable into :theCarIDCAR, :theCarMODEL;

Also, Postgres has built-in Regular Expressions, you'd need UDFs to achieve that in Firebird.

Postgres seems easier to work with, but I haven't made installers for Postgres applications, on the other hand Firebird never gave me problems. (Not a very technical answer, isn't it?)

EDIT: Why not Firebird?: It's good, easy to deploy and works amazingly well, I'm still using it in new projects. Problems: Not easy to find an Internet Server that offers Firebird databases, in fact that's the reason why we used Postgres for that project.