Firebird servers come in two flavours, called architectures: Classic Server and Superserver. Since Firebird 2.5, Classic Server can operate in two modes: “traditional” Classic and Superclassic, giving a total of 3 models. Which one should you choose? The most important differences are listed below. In the vast majority of cases, all three models perform equally well and offer (almost) the same possibilities.

Processes

Classic uses a separate process for each connection; Superclassic and Superserver use a single process. Thus, if a Classic server process crashes, the other connections remain unaffected. With Superclassic and Superserver, a crash take down all the connections.

Guardian

Superserver can run under the control of the Firebird Guardian, which automatically restarts it in case of a crash. Superclassic only offers the Guardian option under Linux. Classic doesn't offer it at all.

Resources

Being single-process, Superclassic and Superserver use system resources more efficiently than Classic if the number of simultaneous connections grows. Superserver is the most efficient of the three, because it also has a shared cache space.

Local connections

Classic and Superclassic offer an embedded local connection mode on Linux which is very fast, but not as secure as a regular network connection. On Windows, a separate Embedded Server is available which is even less secure, but can be very practical if you want to ship Firebird with your applications.

Simultaneous connections

Only Classic and Superclassic allow simultaneous connections to a database from the regular server and one or more embedded servers. Thus, if you use the Windows Embedded Server, it may be advantageous to have Classic or Superclassic as your regular server.

Multiprocessing

On Windows, Superserver defaults to using only the first processor or core in your computer. To make it use all the available CPU power, the CpuAffinityMask parameter in firebird.conf must be edited. All other servers (including Superserver for Linux) support multiprocessing out of the box and ignore CpuAffinityMask.

As you can see, none of the three models outshines the other two on all fronts. If you're not sure which is best for you, SuperClassic may be a good pick on 64-bit systems. Make sure you install the 64-bits version, though. On 32-bits systems, SuperClassic will be the first to run out of memory under high load. Superserver, with its shared cache space, and Classic, with its separate processes, perform better there.

Notice that you can always switch to another model later; your applications and databases will keep functioning like before. The differences are in the servers, not in the databases.

For a more detailed look at the various server models, consult the appendix Firebird server architectures.

back to top of page

For Linux, Superserver download packages start with FirebirdSS, Classic/SuperClassic packages with FirebirdCS. The default run mode for Classic/SuperClassic installations is traditional, multiprocess Classic. To switch to SuperClassic, run the script changeMultiConnectMode.sh and answer “thread” at the prompt (for multithreaded). The script is located in the bin subdirectory of your Firebird installation.

For Windows, there is a combined installation package; you choose the architecture (Superserver or Classic) on one of the first screens. If you choose Classic, you can enable SuperClassic mode a couple of screens later.

On Windows platforms, the Embedded Server comes in a separate download package. It contains a client and server combined into one DLL for ease of deployment. While very practical, it lacks most of Firebird's usual security features (much more so than Linux's embedded local access). For more information on Windows Embedded Server, consult the Clients and Servers chapter in Using Firebird:

https://www.firebirdsql.org/manual/ufb-cs-embedded.html (HTML) https://www.firebirdsql.org/pdfmanual/Using-Firebird_(wip).pdf (PDF)

Please notice! At the time of this writing, the information at the URLs above is not yet up to date with the situation in Firebird 2.5. The most important change is:

• Windows Embedded now contains a Superclassic instead of a SuperServer engine. File locks are shared, so a database can be accessed by one or more Embedded servers and a regular Classic or Superclassic server at the same time.

Consult the Firebird 2.5 Release Notes for full details.