OpenReplay leva observability de front-end a bilhões de eventos por dia com ClickHouse
Aprofundamento CEVIU
Aprofundamento
A OpenReplay é uma plataforma self-hosted de session replay e analytics de produto, feita para devs reproduzirem bugs vendo o que o usuário fez. Segundo o fundador e CEO, Mehdi Osman, é "observability para engenheiros de front-end". A stack é open source e combina ClickHouse, Postgres, Kafka e Redis, e o pipeline é escrito em Go.
O problema começou em 2019, quando tudo rodava em Postgres. A busca de sessões, que combina tipos de evento em sequência, levava cerca de 3 segundos e chegava a 10 mesmo com índices, particionamento e sharding. No ClickHouse, a média caiu para cerca de um segundo. Tabelas de eventos de aproximadamente 1 TB no Postgres ficaram com 1 ou 2 GB. A retenção, antes feita com scripts, deletes e vacuum que travavam tabelas, virou uma regra de TTL definida na instalação. Hoje há duas tabelas principais (sessions e events) e uma cadeia de materialized views processa cada insert. Uma mudança que levava dois dias passou a levar meio dia. O JSON nativo viabilizou eventos customizados, e o query cache foi ativado recentemente. Os maiores clientes chegam a bilhões de eventos e cerca de 6 TB por dia, em uma única instância escalada na vertical, no Kubernetes no caso de um cliente fintech.
O que mudou
A cobertura anterior do CEVIU traz casos parecidos de ClickHouse, mas de outras empresas. Em 30 de setembro de 2026, o CEVIU noticiou "Bolna migra do BigQuery para ClickHouse, reduzindo custos em 6x e otimizando disponibilidade de dados", que também moveu lógica para views materializadas. Em 10 de agosto de 2026, saiu o caso da Physical Intelligence, que separou transacional no PostgreSQL e analítico de alta cardinalidade no ClickHouse. É a mesma divisão de papéis que a OpenReplay adotou, mas não é evolução do mesmo projeto.
Por que isso importa
Para quem opera analytics sobre Postgres, o relato sugere uma leitura prática: o ganho não vem só de velocidade de consulta, mas de tirar da operação tarefas como vacuum e limpezas manuais. Para quem entrega produto no ambiente do cliente, escalar na vertical uma única instância pode reduzir custo operacional, embora a própria OpenReplay diga que, se fosse só SaaS, provavelmente usaria o ClickHouse Cloud.
Linha do tempo
CEVIU noticia a Physical Intelligence dividindo dados entre PostgreSQL e ClickHouse.
CEVIU noticia a migração da Bolna do BigQuery para ClickHouse, com views materializadas.
OpenReplay detalha bilhões de eventos por dia em uma instância de ClickHouse.
Perguntas frequentes
O que é a OpenReplay?
É uma plataforma open source e self-hosted de session replay e analytics de produto. Ela mostra o que o usuário fez no app para ajudar devs a reproduzir bugs e entender atritos.
Por que a OpenReplay saiu do Postgres para o ClickHouse?
O Postgres não é um banco analítico, e buscas de sessões levavam cerca de 3 a 10 segundos. Sharding gerava complexidade operacional. No ClickHouse, a média caiu para cerca de um segundo e o armazenamento encolheu bastante.
Como o TTL ajudou na retenção de dados?
A retenção é definida uma vez na instalação, por exemplo de um mês a um ano. Isso substituiu scripts de delete e vacuum que travavam tabelas e exigiam coordenação em fins de semana com cada cliente.
Eles usam cluster ou sharding no ClickHouse?
Não. Cada implantação roda em uma única instância, e a equipe adiciona RAM e CPU conforme o cliente cresce. Isso mantém o custo operacional baixo no modelo self-hosted.
Fontes
- clickhouse.comfonte original
- Categoria
- CEVIU Web Dev
- Publicado
- 22 de outubro de 2026
- Editoria
- CEVIU Web Dev

