Desde sua primeira versão, o Firebird foi disponibilizado em dois modos de operação (chamados de arquiteturas) diferentes, a SuperServer e a Classic. Na SuperServer as conexões aos bancos de dados são gerenciadas com múltiplas threads em um único processo do SO, enquanto que na Classic é aberto um processo para cada conexão realizada.

A vantagem da arquitetura SuperServer é que diversas conexões a um mesmo banco de dados são gerenciadas com apenas um cache de dados e metadados. Sua desvantagem é que, internamente, a execução de queries é feita de maneira cooperativa, isto é, em determinados pontos uma query paralisa sua própria execução e passa o controle para que outra query continue executando, não aproveitando adequadamente os recursos de máquinas com mais de um processador ou núcleo. Nota: O time de desenvolvedores do Firebird trabalha para remover completamente esta limitação na versão 3, e a SuperClassic é o primeiro passo em busca desse objetivo. Outra desvantagem da SuperServer é que apenas um processo pode abrir cada banco de dados. Isto causava uma limitação em aplicativos que usavam a biblioteca Embedded, como veremos mais adiante.

Na arquitetura Classic cada processo pode executar queries paralelamente, de forma preemptiva, porém cada um possui seu exclusivo cache. Para manter a integridade, o Firebird precisa realizar comunicação inter-processo através de seu lock manager. Essa comunicação causa uma perda de desempenho em relação à SuperServer. Nesta arquitetura também existia a possibilidade de trabalhar com diversas conexões em apenas um processo, porém com a mesma limitação presente na SuperServer, onde as queries de um mesmo processo rodavam de maneira cooperativa. Além disso, esta possibilidade existia apenas com a versão Embedded para Linux, pois rodando no modo servidor a criação de novos processos era sempre feita automaticamente a cada conexão.

O novo modo SuperClassic é uma mistura das duas arquiteturas preexistentes. Um processo SuperClassic pode gerenciar diversas conexões usando threads, como no SuperServer. Mas, diferentemente do SuperServer, cada conexão possui seu cache exclusivo, como no Classic. Como o cache não é compartilhado, as queries podem rodar de maneira preemptiva, melhorando o desempenho em máquinas multiprocessadas.

A arquitetura SuperServer também teve uma melhoria. Até a versão 2.1 as queries eram sincronizadas por servidor, e na versão 2.5 são sincronizadas por banco de dados. Isto significa que um servidor 2.5 gerenciando conexões a vários bancos de dados aproveitará os recursos de hardware de forma mais satisfatória.

Além de SuperServer e Classic, o Firebird também é disponibilizado como uma biblioteca: a versão Embedded. Até a versão 2.1 a biblioteca Embedded trabalhava no modo SuperServer no ambiente Windows e no modo Classic em outros SOs. Na versão 2.5 a biblioteca Embedded usa o modo SuperClassic em todos os SOs. Como o SuperClassic é o Classic melhorado, tornou-se possível o acesso simultâneo a um banco de dados por diversos aplicativos usando a biblioteca Embedded, removendo esta limitação que existia em ambientes Windows. Nota: o compartilhamento de um banco de dados em vários processos Classic (ou Embedded) é permitido apenas quando todos os processos sejam da mesma arquitetura, 32 ou 64 bits. Com a mudança de arquitetura da versão Embedded, o desenvolvedor precisa verificar se o desempenho de seu aplicativo foi influenciado negativamente, pois a configuração padrão de buffers dos bancos de dados são diferentes nas duas arquiteturas. Esta configuração pode ser ajustada alterando-se o valor do parâmetro DefaultDbCachePages no arquivo firebird.conf ou com o comando gfix -buffers em cada banco de dados.