Classic or Superserver?

Embedded Server for Windows

Firebird comes in two flavours, called architectures: Classic Server and Superserver. Which one should you install? That depends on your situation. A short overview of the most important differences follows.

Table 1. Firebird 2 Classic Server vs. Superserver

	Classic Server	Superserver
Processes	Creates a separate process for every client connection, each with its own cache. Less resource use if the number of connections is low.	A single process serves all connections, using threads to handle requests. Shared cache space. More efficient if the number of simultaneous connections grows.
Local connections	Permits fast, direct I/O to database files for local connections on Linux. The client process must have filesystem-level access rights to the database for this to work.	On Linux, all local connections are made via the network layer, using `localhost` (often implicitly). Only the server process needs access rights to the database file.
Local connections	On Windows, both architectures now support safe and reliable local connections, with only the server process requiring access rights to the database file.
Multiprocessor	SMP (symmetrical multi-processor) support. Better performance in case of a small number of connections that do not influence each other.	No SMP support. On multi-processor Windows machines, performance can even drop dramatically as the OS switches the process between CPUs. To prevent this, set the `CpuAffinityMask` parameter in the configuration file `firebird.conf`.
Guardian	When run as a Windows application (as opposed to a service) you can't use the Firebird Guardian. Note that running Firebird as an application is the only option on Windows 9x–ME.	Can be used with the Guardian on Windows, whether run as an application or as a service.
Events	Can't use Fiebird events if the server is behind a firewall or if connections are made through a secure tunnel.	Can use Fiebird events under all circumstances. If the server is behind a firewall or if connections are made through a secure tunnel, a specific events port has to be assigned to the `RemoteAuxPort` variable in `firebird.conf`, and the firewall or tunnel configured accordingly.

As you can see, neither of the architectures is better in all respects. This is hardly surprising: we wouldn't maintain two separate architectures if one of them was an all-fronts loser.

If you're still not sure what to choose (maybe you find all this tech talk a little overwhelming), use this rule of thumb:

On Windows, choose Superserver.
On Linux, just pick one or the other (unless you use events with a firewall or tunnel). In most circumstances, chances are that you won't notice a performance difference.

Note that you can always switch to the other architecture later; your applications and databases will keep functioning like before.

For Linux, Superserver download packages start with FirebirdSS, Classic packages with FirebirdCS. For Windows, there is a combined installation package; you choose the architecture during the installation process.

Embedded Server for Windows

On Windows platforms only, Firebird offers a third flavor: Embedded Server, a client and server rolled into one DLL for ease of deployment. While very practical, it lacks most of Firebird's usual security features. For more information on Firebird Embedded Server, consult the Clients and Servers chapter in Using Firebird:

http://www.firebirdsql.org/manual/ufb-cs-embedded.html (HTML)

http://www.firebirdsql.org/pdfmanual/Using-Firebird_(wip).pdf (PDF)

The Embedded Server comes in a separate download package.