Voltar
Observability de front-end em escala com ClickHouse

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

  1. CEVIU noticia a Physical Intelligence dividindo dados entre PostgreSQL e ClickHouse.

  2. CEVIU noticia a migração da Bolna do BigQuery para ClickHouse, com views materializadas.

  3. 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

Avalie este artigo:
Categoria
CEVIU Web Dev
Publicado
22 de outubro de 2026
Editoria
CEVIU Web Dev

Quer receber mais sobre CEVIU Web Dev?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser