maneira. Uma para cada banco de dados. Se voce tiver apenas um banco de dados o limite ainda se aplica.ClassicServerNo Classic, cada cliente tem um cache proprio e esta conectado a um processo dedicado.O cache dedicado e muito menos eficiente. Se dois clientes acessam a mesma area do banco de dados, esta area sera copiada no cache de cada um deles. Usando o exemplo anterior, quando o cliente B executasse seu comando, ele nao teria o beneficio de um cache ja preenchido e o Firebird precisaria acessar o disco novamente para responder.Alem do mais, a sincronizacao entre os caches e feita atraves do disco. Isto aumenta consideravelmente o custo de I/O para ambientes de alta concorrencia.Veja no diagrama:Um grande beneficio deste modelo e a resiliencia oferecida pelos multiplos processos. Se um deles tiver problemas, apenas o cliente conectado a ele sera desconectado. Todo o restante do banco de dados continua funcionando normalmente.O outro grande beneficio e a escalabilidade. Acredito que esta caracteristica seja a responsavel por boa parte das instalacoes do ClassicServer. Mesmo em casos onde o cache dedicado produz resultados inferiores ao cache compartilhado do Superserver, a escalabilidade do ClassicServer compensa. Basta adicionar mais hardware e pronto, seu servidor fica mais rapido.Mas esta escalabilidade nao vem de graca. Imagine que voce tem 200 clientes simultaneos. Sao 201 processos, um para cada cliente e mais um para ficar ouvindo novas conexoes. Seu sistema operacional deve gerenciar todos estes processos e mante-los em sincronia. Eles consomem muitos recursos de kernel e isto significa que ele pode ser relativamente lento.Veja neste exemplo: Firebird 2.5 Alpha 1 Classic com 7 clientes conectados. Sao 8 processos, 18 threads, 1050 identificadores.SuperClassica partir do Firebird 2.5A equipe de desenvolvimento decidiu usar o Firebird Classic Server como base para construir o Firebird 3.0, que sera totalmente compativel com SMP. O SuperClassic e o primeiro passo nessa direcao. E uma evolucao do Classic Server que resolve o maior problema que o Classic Server tem: Todos aqueles processos o deixam lento e tornam a manutencao mais dificil.Bem-vindo ao SuperClassic: Um unico processo com cache dedicado.Olhando assim e levando em consideracao o nome, parece um hibrido entre o Classic e o Super, mas nao e. O que fizeram foi encapsular todos aqueles processos em threads. Agora cada cliente tem um thread dedicado dentro de um unico processo.Criar centenas de threads e muito mais barato que criar centenas de processos e nao existe perda de escalabilidade. A sincronizacao entre os caches pode ser feita diretamente em memoria, o que reduz o custo de I/O. E outros controles que antes eram inter-processo agora sao inter-thread, muito mais rapidos.Veja exemplo comparavel ao Classic: Firebird 2.5 Alpha 1 SuperClassic com 7 clientes conectados, 1 processo, 6 threads, 172 identificadores.ConclusaoEsta compilacao dos casos mais comuns de uso e uma sugestao e serve apenas como guia, um ponto inicial na sua escolha. A sua instalacao pode ter detalhes proprios que nao foram abordados aqui.SuperServer Bases de dados pequenas ou pouco acessadasServidores pequenosAmbientes onde o cache compartilhado e mais vantajoso que a escalabilidade do SuperClassicClassicServer Ambientes onde a estabilidade