Superclassic is an alternative mode of operation of the Firebird Classic model that was introduced with the v.2.5 Classic servers.

These instructions do not apply to Superserver.

About the Classic Server Modes

The default mode of operation for an out-of-the-box Firebird 2.5 Classic installation is to have the [x]inetd daemon listening for remote connection requests and to operate one instance of the fb_inet_server process for each connection. Each connection therefore has its own copy of the database cache.

In the Superclassic mode, a specialised process called fb_smp_server becomes the listener and the [x]inetd daemon is not involved at all. This process is responsible for spawning threaded instances of fb_inet_server for each successful connection request. The database cache is shared amongst all active connections.

IMPORTANT: Although both Classic and Superclassic are available in both 32-bit and 64-bit versions, it is not recommended to try to run Superclassic on 32-bit production installations of more than a few users, due to the resource limitations that apply to 32-bit applications. Classic remains the recommended model to use on well-resourced 32-bit servers.

NOTE: Don't do this while any fb_smp_server or fb_inet_server process is running.

The interactive script is provided in the Firebird 2.5 ./bin directory beneath the Firebird root directory. To complete the installation of the Superclassic server requires running this script, regardless of whether you installed the Classic package from the RPM kit or the tarball.

In the $firebird-root$/bin directory, run the script as follows and you will be prompted to choose the mode:

$ ./
Which option would you like to choose: multi-(process|thread) [process] ?

To select Superclassic, enter 'm' (without the quotes)

If you want to revert to Classic, enter 'p' (without the quotes)


Several parameters in the firebird.conf configuration file in Firebird's root directory will affect the way the server runs in Superclassic mode. Pay particular attention to DefaultDbCachePages.

NOTE: Contrary to previous information provided here, Superclassic does NOT provide a shared cache for all its process threads. Each thread has an individual cache so it will be important to allocate cache wisely, just as one would for Classic.

Parameters pertaining to locking and shared memory (names starting with 'Lock--') may also prove to be of interest as you test Superclassic under production conditions.

Remember to restart the SuperClassic server after changing parameters in firebird.conf.