--- term: 'PaaS vs. BaaS' seoTitle: 'O que é PaaS? Platform as a Service vs. BaaS Explicado' headline: 'O que é PaaS (Platform-as-a-Service)?' slug: paas-vs-baas category: cloud-architecture shortDefinition: 'PaaS é um modelo de nuvem em que o provedor executa a plataforma onde seu código é implantado, enquanto você ainda escreve e mantém a aplicação.' relatedTerms: - baas-vs-custom-backend - infrastructure-as-a-service - serverless-architecture - cloud-vendor-lock-in - baas-vs-serverless contrastsWith: - infrastructure-as-a-service aboutTerms: - 'Platform-as-a-Service (PaaS)' - 'Backend-as-a-Service (BaaS)' faq: - question: 'O que é PaaS em termos simples?' answer: 'PaaS significa alugar a plataforma em vez das máquinas. O provedor é dono dos servidores, do sistema operacional, do runtime e do ferramental de deploy; você faz push do código da sua aplicação e ela é construída, executada e mantida no ar. Você ainda escreve e mantém a aplicação inteira — a plataforma só remove o trabalho de infraestrutura por baixo dela.' - question: 'Qual a diferença entre IaaS, PaaS e SaaS?' answer: 'São degraus de uma escada de abstração definida por quem gerencia o quê. IaaS aluga infraestrutura bruta — máquinas virtuais, armazenamento, rede — e tudo do sistema operacional para cima é trabalho seu. PaaS aluga uma plataforma gerenciada: você traz apenas código de aplicação e dados. SaaS é o degrau do topo: uma aplicação pronta que você simplesmente usa. Cada degrau acima troca controle por velocidade.' - question: 'Qual a diferença entre PaaS e BaaS?' answer: 'O PaaS dá um lugar para rodar o backend que você ainda precisa escrever; o BaaS dá o backend em si. Num PaaS você escreve a aplicação de servidor — rotas, auth, fiação do banco — e a plataforma a hospeda. Num BaaS, funcionalidades padrão como autenticação, CRUD no banco e armazenamento de arquivos vêm prontas e são consumidas por SDKs de cliente, então, nos casos comuns, não há aplicação de servidor para escrever.' - question: 'PaaS é a mesma coisa que serverless?' answer: 'Não. Uma aplicação PaaS normalmente roda de forma contínua em instâncias que você configura e paga, e só escala conforme configurado. A computação serverless é provisionada por evento: funções sobem sob demanda, cobram por invocação e tempo de execução, escalam a zero quando ociosas e podem pagar a multa do cold start na primeira requisição. PaaS é hospedar um app sempre ligado; serverless é rodar código só quando algo acontece.' - question: 'Kubernetes ou Docker são um PaaS?' answer: 'Não — são blocos de construção open source, não plataformas. O Docker empacota aplicações em containers; o Kubernetes orquestra containers entre máquinas. Um PaaS pode ser construído em cima deles e esconder essa complexidade atrás de um comando de deploy. Se o seu time opera Kubernetes diretamente, você está mais perto de um IaaS com ferramentas melhores do que de um PaaS.' - question: 'Quais são as desvantagens do PaaS?' answer: 'As mais citadas são o vendor lock-in (apps escritos contra serviços específicos da plataforma custam caro para mover), o controle reduzido sobre runtime e sistema operacional, preços que podem subir bastante em escala sustentada, a dependência do uptime e das decisões de produto do provedor e as restrições de compliance quando a regulação exige controle da infraestrutura. Escolher plataformas baseadas em padrões abertos ou open source suaviza a maior parte disso.' - question: 'Como o PaaS é cobrado?' answer: 'Tipicamente por instância em execução ou tier de recursos, com cobrança mensal ou por hora — você paga pela capacidade que mantém sua aplicação no ar, com ou sem tráfego. Isso torna o custo previsível, mas nunca zero. Contrasta com o preço por invocação do serverless, que cai a zero quando ocioso, e com os planos de BaaS, que costumam agrupar requisições, armazenamento e usuários num free tier mais faixas fixas acima.' - question: 'Quem deveria usar PaaS?' answer: 'Times que querem escrever e manter uma aplicação de servidor própria sem operar infraestrutura: times de produto entregando APIs web, empresas padronizando o deploy de muitos serviços e devs que precisam de controle total da lógica de backend, mas de nenhuma gestão de servidores. Se suas necessidades de backend são majoritariamente padrão — usuários, dados, armazenamento — um BaaS remove até a etapa de escrever a aplicação e costuma ser o caminho mais rápido.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'The NIST Definition of Cloud Computing (SP 800-145)' url: 'https://csrc.nist.gov/pubs/sp/800/145/final' - name: 'Platform as a service (Wikipedia)' url: 'https://en.wikipedia.org/wiki/Platform_as_a_service' - name: 'The Twelve-Factor App methodology' url: 'https://12factor.net' - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)' url: 'https://martinfowler.com/articles/serverless.html' cta: title: 'Pule a plataforma — comece de um backend pronto' text: 'O Back4app entrega o que um PaaS ainda pede que você construa: banco de dados, autenticação, armazenamento de arquivos e APIs já vêm provisionados, com funções Cloud Code para a sua lógica custom. Saia do zero para um backend funcionando em minutos, de graça.' linkText: 'Comece grátis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-08-20' translationKey: paas-vs-baas --- **PaaS é um modelo de nuvem em que o provedor executa a plataforma onde seu código é implantado, enquanto você ainda escreve e mantém a aplicação.** Em bom português: você aluga a plataforma, mas o app continua sendo seu. A [definição do NIST](https://csrc.nist.gov/pubs/sp/800/145/final) traça a linha com precisão — o provedor controla servidores, sistemas operacionais e runtimes; você controla a aplicação implantada e os dados dela. ## Principais pontos | Pergunta | Resposta | | --- | --- | | O que é | Uma plataforma gerenciada que constrói, executa e escala o código que você envia | | O que você ainda faz | Escrever e manter toda a aplicação de servidor | | Problema que resolve | Provisionar servidores, aplicar patches no SO, encanamento de deploy | | Modelo de cobrança | Por instância ou tier — a capacidade fica ligada, com ou sem tráfego | | vs. BaaS | O PaaS hospeda o backend que você escreve; o BaaS entrega o backend pronto | ## Como é usar um PaaS A experiência que define o PaaS é fazer deploy com um comando e nenhum setup de infraestrutura: ```bash # O fluxo típico de PaaS: faça push do código, a plataforma cuida do resto $ git push platform main -----> Runtime detected: Node.js -----> Installing dependencies, building release -----> Launching web process (2 instances) https://my-api.example.app deployed ``` O que esse comando implanta, porém, ainda é uma aplicação de servidor completa que você escreveu — roteamento, validação, fiação do banco, tratamento de auth: ```javascript // server.js — num PaaS, tudo isto continua sendo seu para escrever e manter const app = express(); app.get('/tasks', async (req, res) => { const user = await authenticate(req); // você construiu isto const tasks = await db.query( // e isto 'SELECT * FROM tasks WHERE owner = $1 AND done = false', [user.id] ); res.json(tasks); // e isto }); app.listen(process.env.PORT); ``` Essa é a troca essencial do PaaS: a infraestrutura desaparece, mas a aplicação de backend — com cada patch de segurança, upgrade de dependência e endpoint dela — continua sendo o seu codebase. ## A escada de abstração Cada modelo de serviço em nuvem responde a uma pergunta: quanto você aluga, e quanto ainda executa? ```mermaid flowchart LR accTitle: A escada de abstração da nuvem accDescr: Cinco passos do on-premises passando por IaaS, PaaS e BaaS até SaaS, em que cada degrau aluga mais da stack — as máquinas, depois a plataforma, depois o backend e, por fim, a aplicação pronta. A["On-premises
execute tudo você mesmo"] --> B["IaaS
alugue as máquinas"] B --> C["PaaS
alugue a plataforma"] C --> D["BaaS
alugue o backend"] D --> E["SaaS
alugue a aplicação pronta"] ``` A divisão de responsabilidade, camada por camada: | Camada | On-prem | IaaS | PaaS | BaaS | SaaS | | --- | --- | --- | --- | --- | --- | | Código da aplicação | Você | Você | Você | Só a lógica custom | Provedor | | Funcionalidades de backend (auth, CRUD, storage) | Você | Você | Você | Provedor | Provedor | | Runtime e middleware | Você | Você | Provedor | Provedor | Provedor | | Sistema operacional e patching | Você | Você | Provedor | Provedor | Provedor | | Servidores, armazenamento e rede | Você | Provedor | Provedor | Provedor | Provedor | Existem sabores especializados de PaaS para trabalhos mais estreitos — plataformas de integração, mobile, banco de dados, comunicação — mas todos ficam no mesmo degrau: um lugar gerenciado para rodar ou conectar o software que você constrói. ## PaaS vs. BaaS: a diferença na prática O BaaS é o degrau seguinte, e a diferença aparece no que você *não* escreve. O endpoint de lista de tarefas acima — checagem de auth, query, resposta — é substituído num BaaS por uma chamada direta de SDK a partir de qualquer cliente, com o controle de acesso aplicado pela plataforma: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK const query = new Parse.Query('Task'); query.equalTo('done', false); query.descending('createdAt'); const tasks = await query.find(); console.log(`${tasks.length} open tasks`); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK final query = QueryBuilder(ParseObject('Task')) ..whereEqualTo('done', false) ..orderByDescending('createdAt'); final response = await query.query(); if (response.success) { print('${response.results?.length} open tasks'); } ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK let query = Task.query("done" == false) .order([.descending("createdAt")]) query.find { result in switch result { case .success(let tasks): print("\(tasks.count) open tasks") case .failure(let error): print(error.localizedDescription) } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK val query = ParseQuery.getQuery("Task") query.whereEqualTo("done", false) query.orderByDescending("createdAt") query.findInBackground { tasks, e -> if (e == null) { Log.d("Tasks", "${tasks.size} open tasks") } } ``` | Dimensão | PaaS | BaaS | | --- | --- | --- | | O que o provedor executa | A plataforma sob o seu app | A plataforma *e* as funcionalidades de backend | | O que você escreve | A aplicação de servidor inteira | Só a lógica custom, como funções | | Unidade de deploy | Uma aplicação | Muitas vezes nada — os clientes chamam SDKs | | Auth, banco, storage, APIs | Seu código, infraestrutura deles | Prontos, expostos via SDKs | | Scaling | Configurado por instância/tier | Automático, atrás de APIs gerenciadas | | Melhor para | Apps de servidor próprios que você quer manter | Backends padrão que você prefere não escrever | ## PaaS vs. serverless Os modelos são primos, não sinônimos. Um app PaaS roda continuamente em capacidade que você configura; a computação serverless se materializa por evento, [cobra por invocação e escala a zero](https://martinfowler.com/articles/serverless.html) — ao preço de cold starts e limites de execução. Na prática, a linha borra: plataformas modernas anexam funções serverless à hospedagem estilo PaaS, e uma [arquitetura serverless](/glossary/pt/arquitetura-serverless/) pode servir uma API inteira que um PaaS hospedaria como um único app. A decisão depende do formato do tráfego: carga estável favorece o processo sempre ligado do PaaS; carga esporádica ou majoritariamente ociosa favorece a computação por invocação. ## Casos de uso comuns - **APIs e serviços web próprios.** Um backend com lógica específica demais para funcionalidades prontas — motores de precificação, marketplaces, ferramentas internas — implantado sem ser dono de servidores. - **Padronizar muitos deploys.** Times com dezenas de serviços adotam um PaaS para que todo serviço construa, implante, logue e escale do mesmo jeito. - **Migrar de servidores autogeridos.** Aplicações de servidor existentes (em especial apps [twelve-factor](https://12factor.net)) se mudam para um PaaS quase sem mudanças — o mesmo código, sem mais patching de SO. - **Onde o BaaS substitui o PaaS: backends de app padrão.** Se o backend é usuários + dados + arquivos + notificações, funcionalidades prontas eliminam a camada de aplicação que o PaaS hospedaria — o caso comum de produtos mobile e web. - **Híbrido: núcleo custom estilo PaaS, BaaS para o resto.** Alguns times mantêm um serviço próprio numa plataforma enquanto gestão de usuários, APIs de dados e storage vêm de um BaaS ao lado. ## PaaS ou BaaS? Uma matriz de decisão | Penda para PaaS quando… | Penda para BaaS quando… | | --- | --- | | O backend *é* o seu produto — lógica custom em tudo | O backend é encanamento padrão ao redor do produto | | Você já tem um codebase de servidor para hospedar | Você está começando do zero e quer pular o codebase | | Você precisa de qualquer linguagem, framework ou protocolo | Seus alvos são plataformas cobertas por SDK (web, mobile) | | Um time de backend mantém a aplicação de servidor | O time é frontend/mobile-first | | O preço por instância combina com tráfego estável | Um free tier e scaling gerenciado combinam com um MVP ou carga esporádica | Se a maioria dos requisitos é padrão mas alguns são custom, isso não é motivo para escolher PaaS — um BaaS com runtime de funções embutido cobre os dois lados com menos código para manter. ## Limitações e trade-offs - **Você ainda mantém uma aplicação.** Upgrades de framework, patches de segurança em dependências, bugs de auth — o PaaS hospeda o seu backend; ele não faz a manutenção. Esse é o custo que o BaaS remove e o PaaS não. - **Vendor lock-in.** Apps escritos contra serviços e formatos de deploy específicos da plataforma custam caro para mover. Mitigações: fique nos padrões abertos, containerize, prefira plataformas construídas sobre open source — a mesma cautela com lock-in vale escada acima e abaixo. - **Custo em escala sustentada.** A conveniência gerenciada carrega uma margem; workloads grandes e estáveis acabam ficando mais baratos nos degraus de baixo — ao preço de recontratar a carga de operações. - **Controle reduzido.** Sem acesso ao SO, tuning de rede limitado e versões de runtime no cronograma do provedor. Regimes de compliance que exigem controle da infraestrutura podem descartar o modelo. - **Dependência do provedor.** Quedas, mudanças de preço e descontinuações chegam no cronograma do provedor, não no seu. Julgue o histórico do provedor como parte da arquitetura. ## PaaS vs. BaaS no Back4app O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Isso o coloca um degrau acima do PaaS: todo app começa com o backend completo já provisionado. A lacuna de lógica custom que puxaria você de volta a um PaaS é coberta pelo **[Cloud Code](https://www.back4app.com/docs/get-started/cloud-functions)** — funções serverless, triggers e jobs agendados. E como a stack é open source, a objeção do lock-in se inverte: o mesmo backend pode ser auto-hospedado em qualquer infraestrutura, então descer a escada mais tarde continua possível, sem reescrita.