Quando eu li o estudo que compara o custo de colocar 1 kg em órbita ao longo do tempo, a sensação foi bem parecida com “ok, então é mesmo engenharia escalando”: o valor caiu cerca de 96% desde 1960 — e isso não aconteceu só porque “os foguetes ficaram mais baratos”. O que pesou foi a combinação de tecnologia, entrada de empresas privadas e, principalmente, uma nova forma de medir custo que inclui quantos quilos o veículo realmente consegue lançar na vida útil. Segundo o OlharDigital.com.br, em 1960 custava US$ 87.023/kg (algo como R$ 478,6 mil) e em 2025 caiu para US$ 3.868/kg (aprox. R$ 21,3 mil). E, pra quem programa sistemas complexos, tem uma lição aqui: métricas erradas te fazem tomar decisões erradas.
Por que “ficou mais barato mandar coisas ao espaço” não é só marketing
Tem um erro comum em discussões técnicas: pegar o preço do hardware e chamar isso de “custo do processo”. Em lançamento espacial, isso costuma falhar por um motivo simples: o preço do foguete é só uma parte do custo total. O resto está no ciclo de vida e no aproveitamento.
Na minha experiência, a analogia é direta com software: você pode olhar só o preço de uma VM e ignorar o custo de falhas, retrabalho e tempo de execução real. O estudo citado pelo OlharDigital.com.br faz algo parecido com o lançamento: não avalia apenas quanto custa o foguete “por disparo”, mas quanto ele transporta durante toda a vida útil do veículo. Aí, a métrica deixa de ser enganosa.
A queda de 96%: o que mudou na prática
O estudo que o OlharDigital.com.br reportou avaliou 4.405 lançamentos entre 1960 e 2025, com mais de 330 configurações e dados de países como EUA, Rússia, China, Índia, Brasil e Japão. Não é só “um foguete novo”. É a evolução do ecossistema inteiro.
- Reutilização: quando você reaproveita motores e estruturas, o custo “fixo” dilui melhor. É como reduzir CAPEX por unidade de entrega.
- Escala: mais lançamentos geram aprendizado e otimização de processos. Em software, isso vira “melhorar pipelines” e diminuir custo por deploy.
- Tecnologia de propulsão e materiais: melhora eficiência, aumenta carga útil e reduz desperdícios.
- Concorrência privada: empresas privadas entram com foco em custo por missão e iteração rápida.
- Método de cálculo mais realista: incluir a carga enviada ao longo da vida útil muda o resultado.
O diferencial técnico do estudo: medir “custo por quilo” do jeito certo
Segundo Francesco Nicoli (Universidade Politécnica de Turim), pesquisas anteriores consideravam “o custo dos foguetes” mas não o quanto eles lançam na vida útil. O problema é que, sem esse fator, você compara maçãs com laranjas.
Eu gosto de pensar assim: se um veículo custa X e consegue lançar N cargas ao longo do tempo, o custo por entrega real depende de N. Ignorar N é ignorar a parte que diz se o processo está melhorando de verdade.
Uma modelagem mental (quase um “equacionamento de engenharia”)
O estudo, na essência, aproxima uma métrica do tipo:
- Custo por kg ≈ (custo total do sistema na vida útil) / (kg totais enviados na vida útil)
Na prática, isso consegue capturar: reutilização, confiabilidade, taxas de sucesso e capacidade real de entrega ao longo do tempo.
Comparação com alternativas reais: por que “barato” pode enganar
Mesmo quando o custo por kg cai, ainda existem armadilhas. O termo “1 kg em órbita” esconde várias dimensões: órbita alvo, janela de lançamento, requisitos de massa e energia, além de custos indiretos (integração, preparação, logística).
Como dev, eu já vi métricas “bonitas” esconderem detalhes críticos. Em lançamento, algumas complicações comuns são:
- Comparar órbitas diferentes: LEO vs GEO não é só “distância”; muda energia e arquitetura.
- Ignorar throughput: capacidade de lançar com frequência afeta aprendizado e custo.
- Sucesso vs tentativa: taxas de falha mudam o custo efetivo por entrega real.
- Custos de suporte: montagem, testes e infraestrutura podem pesar mais que o foguete em si.
- Misturar sistemas: comparar um programa com baixa cadência vs alta cadência é injusto.
O que esperar até 2040
O OlharDigital.com.br indica que a redução pode continuar até 2040. Eu trataria isso como “tendência provável”, não certeza absoluta. Em sistemas complexos, o custo pode cair por anos e depois estagnar por gargalos (materiais, produção de componentes, licenças, limitações de infraestrutura, capacidade de lançamento em certas geografias).
Em outras palavras: custo por kg tende a cair com eficiência e escala, mas sempre há um ponto em que novas melhorias exigem saltos (mais capital, novas tecnologias ou mudanças regulatórias).
Implicações práticas para quem programa (e desenha sistemas)
Eu sei que o tema é espaço, mas a lição é de engenharia e mensuração. Se você é desenvolvedor ou lidera tecnologia, aqui vão implicações diretas:
- Métrica de “custo do componente” não basta: você precisa medir custo por entrega, com janela temporal e ciclo de vida.
- Incluir o “tempo de vida” evita decisões erradas: reutilização e confiabilidade mudam o denominador (quantos kg foram realmente entregues).
- Dados históricos grandes mudam conclusão: o estudo trabalha com 4.405 lançamentos. Em software, isso equivale a ter observabilidade real e logs suficientes.
- O “como” se mede importa mais que o número final: se seu KPI está mal definido, você otimiza para o errado.
Na Prática: como pensar “custo por entrega” no seu sistema
Vou trazer um exemplo funcional no contexto de software, bem no espírito do estudo: trocar “custo por evento” por “custo por entrega acumulada”. Imagine uma equipe que paga por execução de jobs (VM/containers) e quer medir custo real por resultado entregue.
- Defina o denominador certo: “quantos resultados entregues” no período, não apenas “quantas execuções”.
- Some custo ao longo da vida útil: se um recurso é reutilizado (pool), calcule por período/uso total.
- Inclua retries e falhas: falha não é grátis; ela aumenta custo sem aumentar entregas.
- Separe por condições: sucesso com mesmo tipo de tarefa vs tarefas diferentes.
Um snippet em Python para calcular custo por “unidade entregue” (pensa em kg como “entrega”).
from dataclasses import dataclass
from datetime import datetime
@dataclass
class Run:
started_at: datetime
finished_at: datetime
job_type: str
cost_usd: float
delivered_units: float # ex: kg, itens, mensagens entregues (fração permitida)
succeeded: bool
def cost_per_unit(runs, job_type=None):
filtered = [r for r in runs if (job_type is None or r.job_type == job_type)]
total_cost = sum(r.cost_usd for r in filtered)
total_units = sum(r.delivered_units for r in filtered)
if total_units == 0:
return float("inf")
return total_cost / total_units
# Exemplo: reutilização reduz retries e aumenta delivered_units por custo
runs = [
Run(datetime(2025,1,1), datetime(2025,1,1,0,10), "render", 120.0, 2.0, True),
Run(datetime(2025,1,1), datetime(2025,1,1,0,25), "render", 140.0, 1.0, True),
Run(datetime(2025,1,2), datetime(2025,1,2,0,40), "render", 80.0, 0.0, False), # falha aumenta custo sem entrega
]
print("Custo por unidade:", cost_per_unit(runs, "render"))
O ponto aqui é o mesmo do estudo: se você não mede o que realmente foi entregue, você vai concluir “ficou barato” quando na verdade só houve mudança de como o custo aparece na contabilidade.
Erros Comuns (e por que devs caem neles)
1) Otimizar o KPI errado
Em software, isso vira: otimizar custo por execução, mas ignorar entregas. Em espaço, é olhar só o preço do foguete e ignorar quantos quilos ele entrega no tempo.
2) Ignorar o efeito de reutilização
Se um recurso reutiliza, o custo marginal por uso muda. O correto é considerar ciclo de vida e amortização.
3) Comparar períodos com condições diferentes
Eu vejo isso muito em performance: comparar “antes e depois” sem controlar carga, tipo de tarefa e taxa de falha. No estudo, a metodologia usa um conjunto grande e histórico; isso reduz viés.
4) Não tratar falhas como parte do custo
Falha não é evento neutro. Ela custa tempo, dinheiro e afeta throughput. Isso é tão importante quanto sucesso em lançamento.
5) Falta de dados observáveis
Sem logs e métricas, você não calcula custo por entrega. O estudo citado usou um banco grande (4.405 lançamentos). Em engenharia, isso é seu “dataset”.
FAQ
O estudo só olha para o foguete em si, ou também para o que acontece depois?
Segundo o OlharDigital.com.br, a metodologia inclui quanto cada veículo conseguiu lançar durante sua vida útil. Então o custo é distribuído pelo total de carga entregue, não apenas pelo preço do foguete em um disparo específico.
Por que a métrica “por kg” muda tanto o resultado?
Porque ela adiciona o denominador real (quantidade entregue) e reduz o viés de “custo aparente”. Um sistema que reutiliza e aumenta throughput tem melhor custo por entrega, mesmo que o preço de componentes individuais não caia na mesma proporção.
Isso significa que colocar satélites vai ficar sempre mais barato até 2040?
Indica tendência. Mas em sistemas complexos, podem existir gargalos regulatórios, infraestrutura limitada, mudanças no tipo de missão e desafios tecnológicos que desacelerem a queda.
Como eu aplico essa ideia no meu projeto como desenvolvedor?
Troque “custo por execução” por “custo por entrega” e inclua falhas, retries e ciclo de vida dos recursos. Se você mede apenas o componente, você otimiza para o errado.
Quais dados são essenciais para calcular “custo por entrega” corretamente?
Custo total no período, taxa de sucesso/falha, quantidade efetiva entregue (kg/unidades) e fatores de comparação (tipo de tarefa/órbita equivalente). Sem isso, a métrica vira número enganoso.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.