Comparações entre linguagens costumam virar discussão de preferência, com argumentos que não ajudam ninguém a decidir nada.

Este artigo tenta outra coisa: partir do pressuposto de que as duas tecnologias resolvem bem a maior parte dos problemas, e olhar para o que efetivamente muda depois da decisão — no servidor, no dimensionamento, na publicação e na operação do dia a dia.

Porque essa parte muda, e muda bastante. E raramente entra na conversa quando a escolha é feita.

A diferença que origina todas as outras

Existe uma distinção de modelo de execução, e quase tudo decorre dela.

No modelo tradicional do PHP, cada requisição é atendida por um processo que começa do zero, executa e termina. Nada persiste entre requisições. Isso tem uma consequência prática notável: um vazamento de memória em uma requisição não afeta a próxima, porque o processo acabou.

No Node.js, a aplicação é um processo permanente que atende muitas requisições ao longo do tempo. Isso permite manter coisas em memória entre elas — conexões, caches, estado — e torna as conexões persistentes viáveis. Também significa que problemas se acumulam: um vazamento cresce, e um erro não tratado pode derrubar o processo inteiro.

Vale a ressalva honesta: o PHP moderno também permite processos permanentes, com modos de execução que mantêm a aplicação carregada entre requisições. Isso aproxima os dois modelos e muda parte da comparação clássica. Mas o modelo tradicional continua sendo o mais usado, e é o que a maior parte das equipes vai operar.

Comparação por consequência de infraestrutura

Aspecto	PHP (modelo tradicional)	Node.js
Unidade de dimensionamento	Processos por requisição	Trabalhadores permanentes
Estado entre requisições	Não persiste	Persiste
Vazamento de memória	Contido pelo fim do processo	Acumula, exige reinício
Conexões persistentes	Inadequado	Adequado
Publicação	Trocar arquivos costuma bastar	Exige reiniciar processos
Supervisão	Gerenciada pelo servidor web	Necessária e configurada por você
Tarefas em segundo plano	Fila com trabalhadores	Fila com trabalhadores
Ambiente compartilhado	Amplamente disponível	Raramente disponível

Três linhas concentram o que realmente importa na decisão.

1. Publicação e supervisão

A diferença operacional mais sentida no dia a dia.

Em uma aplicação PHP tradicional, publicar pode ser tão simples quanto substituir os arquivos: a próxima requisição já usa o código novo, porque cada uma começa do zero. Em aplicações com framework existem etapas adicionais — dependências, migrações, caches —, tratadas no artigo sobre publicar uma aplicação PHP moderna, mas o princípio se mantém.

Em Node.js, o código fica carregado na memória do processo. Trocar os arquivos não muda nada até reiniciar — e reiniciar significa derrubar as conexões ativas, exigindo uma estratégia de publicação que o modelo tradicional dispensa.

A mesma lógica vale para supervisão: no modelo tradicional, o servidor web administra os processos e reinicia o que falhar. Em Node.js, é preciso um supervisor configurado por você para que a aplicação volte após um erro ou uma reinicialização do servidor.

Isso não torna o Node.js pior — torna a operação um pouco mais elaborada, e essa elaboração precisa caber na capacidade da equipe.

2. Comportamento sob carga

O ponto onde a comparação costuma ser mal feita.

A afirmação de que o Node.js é mais rápido é imprecisa. O que ele faz melhor é aproveitar os períodos de espera: enquanto uma requisição aguarda o banco de dados ou uma API externa, o mesmo processo atende outras. No modelo tradicional, cada processo em espera fica ocupado sem fazer nada.

Isso significa uma vantagem real e delimitada:

• Em aplicações que passam muito tempo esperando — APIs que agregam dados de vários serviços, por exemplo —, o Node.js atende mais requisições simultâneas com menos recursos.
• Em aplicações que processam de fato — transformam dados, geram documentos, calculam —, a vantagem desaparece. O trabalho ocupa o processador nos dois casos.
• Em aplicações típicas de negócio, com consultas ao banco e regras moderadas, a diferença raramente é o fator decisivo de custo.

A ressalva que vale mais que a comparação: uma consulta mal construída ao banco de dados custa mais que qualquer diferença entre as duas linguagens. Otimizar o acesso a dados rende mais que escolher a tecnologia por desempenho.

Os métodos de medição de cada uma estão nos artigos sobre dimensionar um servidor para Node.js e sobre o servidor para PHP.

3. Onde a aplicação pode rodar

A diferença mais prática e a menos discutida.

PHP roda em praticamente qualquer hospedagem, inclusive nos planos compartilhados mais simples. Isso reduz o custo de entrada e simplifica a operação para projetos pequenos.

Node.js exige manter processos permanentes ativos, o que ambientes compartilhados raramente permitem. Na prática, isso significa um servidor com controle administrativo desde o primeiro dia — o assunto do artigo sobre hospedagem compartilhada ou Cloud Server.

A consequência de custo: um projeto pequeno em PHP pode começar muito barato; o mesmo projeto em Node.js começa com um servidor. Isso importa para validação de ideias e projetos de baixo orçamento, e deixa de importar conforme o projeto cresce — porque acima de certo porte, os dois vão precisar de servidor de qualquer forma.

O que é igual nos dois

A parte que costuma surpreender quem espera diferenças maiores:

• Fila para trabalho pesado. Os dois precisam, pelas mesmas razões, com os mesmos requisitos — o conceito está no artigo sobre o que é uma fila de tarefas.
• Proxy reverso na frente, com HTTPS e renovação automática.
• Segredos em variáveis de ambiente, fora do código.
• Backup com restauração testada.
• Monitoramento de disponibilidade, recursos e comportamento.
• Limite de conexões do banco como restrição frequente.
• Ambiente de homologação para testar antes de publicar.
• Atualizações de segurança da linguagem e das dependências.

Essa lista é a maior parte do trabalho de infraestrutura — e ela não muda com a escolha. O que a decisão altera é um conjunto menor de coisas do que a discussão sugere.

O que deveria pesar de verdade

Cinco critérios que costumam decidir melhor que desempenho:

1. O que a equipe domina. Uma equipe experiente em uma tecnologia entrega mais rápido e com menos erro que a mesma equipe aprendendo outra. Esse fator supera quase todos os demais.
2. O ecossistema do problema. Se o projeto envolve um sistema de conteúdo consolidado, integrações prontas ou uma base existente, a tecnologia dessa base tem peso.
3. A necessidade de tempo real. Se o produto exige conexões persistentes — notificações, chat, painéis ao vivo —, o Node.js tem vantagem estrutural, como tratado no artigo sobre conexões persistentes e tempo real.
4. A capacidade de operação. Processos permanentes e supervisão exigem alguém que saiba mantê-los.
5. A contratação. Qual perfil você consegue contratar na sua região e faixa de orçamento.

O primeiro critério merece ênfase porque contraria a forma como a discussão costuma acontecer: a produtividade da equipe tem efeito muito maior no resultado do projeto que a diferença técnica entre as duas opções.

Quando cada uma tende a fazer mais sentido

Sem torcida, e reconhecendo que os cenários se sobrepõem:

PHP tende a fazer sentido quando

• O projeto se apoia em um sistema de conteúdo consolidado.
• A equipe já trabalha com ele.
• O orçamento inicial é restrito e o ambiente compartilhado atende.
• O ecossistema tem soluções prontas para o problema.
• A operação precisa ser simples, com pouca infraestrutura para manter.

Node.js tende a fazer sentido quando

• O produto precisa de conexões persistentes ou tempo real.
• A aplicação faz muitas chamadas a serviços externos.
• A equipe de front-end também escreve o back-end.
• O projeto já exige um servidor por outros motivos.
• Há necessidade de compartilhar código entre front-end e back-end.

O terceiro item do segundo grupo é um argumento organizacional, não técnico — e é frequentemente o que decide na prática, com boas razões: uma equipe única que domina as duas pontas trabalha com menos atrito.

E se for preciso trocar

Uma observação para quem avalia migrar uma aplicação existente.

Reescrever uma aplicação funcional em outra linguagem é um dos projetos com pior relação entre custo e retorno que existem — a menos que exista um motivo estrutural, e insatisfação com a tecnologia não é um.

Motivos que justificam:

• A aplicação precisa de um recurso que a tecnologia atual não comporta bem.
• Não é possível contratar quem a mantenha.
• A base de código está inviável por outras razões, e a reescrita aconteceria de qualquer forma.

E uma alternativa que costuma ser melhor: migrar por partes. Extrair um serviço específico para a nova tecnologia, mantendo o restante, entrega valor sem parar a operação — e às vezes revela que a reescrita completa não era necessária.

Conclusão

A escolha entre Node.js e PHP para uma API muda menos coisas do que a discussão sugere. A maior parte do trabalho de infraestrutura — fila, proxy, backup, monitoramento, homologação, limite de conexões — é idêntica nas duas.

O que muda de fato: o Node.js exige supervisão de processos e uma estratégia de publicação que o modelo tradicional dispensa, e exige um servidor desde o primeiro dia. Em troca, ele aproveita melhor os períodos de espera e torna viáveis recursos de tempo real.

E o critério que deveria pesar mais que desempenho: o que a equipe domina. A produtividade de quem constrói tem efeito maior no resultado que a diferença técnica entre as opções. Conheça os Cloud Servers da TBF Host e avalie o ambiente adequado à tecnologia que você escolher.

Perguntas frequentes

Node.js é mais rápido que PHP?

A afirmação é imprecisa. O Node.js aproveita melhor os períodos de espera: enquanto uma requisição aguarda o banco ou uma API externa, o mesmo processo atende outras. Em aplicações que processam de fato, a vantagem desaparece. E uma consulta mal construída custa mais que qualquer diferença entre as duas.

Qual a principal diferença de infraestrutura entre Node.js e PHP?

O modelo de execução. No PHP tradicional, cada requisição é atendida por um processo que começa do zero e termina. Em Node.js, a aplicação é um processo permanente — o que permite manter estado em memória, mas exige supervisão configurada e reinício a cada publicação.

Posso hospedar uma aplicação Node.js em hospedagem compartilhada?

Raramente. Manter processos permanentes ativos é um requisito que ambientes compartilhados quase nunca permitem. Na prática, Node.js exige um servidor com controle administrativo desde o primeiro dia, enquanto PHP roda em praticamente qualquer plano.

O que muda na publicação de uma aplicação Node.js?

O código fica carregado na memória do processo, então trocar os arquivos não tem efeito até reiniciar. E reiniciar derruba as conexões ativas, o que exige uma estratégia de publicação que o modelo tradicional do PHP dispensa, já que ali cada requisição começa do zero.

PHP ainda faz sentido para APIs novas?

Sim, especialmente quando a equipe domina a tecnologia, o projeto se apoia em um ecossistema consolidado ou o orçamento inicial é restrito. O PHP moderno também oferece modos de execução com processos permanentes, o que aproxima os dois modelos e muda parte da comparação clássica.

O que é igual nos dois em termos de infraestrutura?

Quase tudo: fila para trabalho pesado, proxy reverso com HTTPS, segredos fora do código, backup com restauração testada, monitoramento, limite de conexões do banco, ambiente de homologação e atualizações de segurança. É a maior parte do trabalho, e não muda com a escolha.

Qual critério deveria pesar mais na escolha?

O que a equipe domina. Uma equipe experiente em uma tecnologia entrega mais rápido e com menos erro que a mesma equipe aprendendo outra — e esse efeito no resultado do projeto é maior que a diferença técnica entre as opções.

Vale a pena reescrever uma aplicação PHP em Node.js?

Só com motivo estrutural: um recurso que a tecnologia atual não comporta, impossibilidade de contratar quem mantenha, ou uma base de código já inviável. Insatisfação com a tecnologia não justifica. Migrar por partes, extraindo um serviço específico, costuma ser melhor que reescrever tudo.