Startups e médias empresas geralmente começam sua jornada de infraestrutura com um único banco de dados relacional monolítico — na imensa maioria das vezes, o PostgreSQL. Inicialmente, essa é uma decisão incrivelmente sensata. O Postgres lida com conformidade ACID, chaves estrangeiras, constraints e joins complexos com uma confiabilidade invejável.
Ele sustenta sessões de usuários, sistemas de senhas, validação de segurança e configurações do core do aplicativo. Este é o domínio onde ele brilha: OLTP (Online Transaction Processing).
Contudo, à medida que a plataforma cresce e o negócio passa a demandar dashboards pesados, cruzamento de métricas históricas de anos e filtros multidimensionais, o tempo de resposta simplesmente desmorona. As “soluções” de sempre são aplicadas: joga-se mais RAM na face do servidor RDS, indexam-se tabelas agressivamente e constroem-se Materialized Views.
Com o evento dos bilhões de linhas, uma verdade inquestionável se revela: É impossível otimizar permanentemente um motor OLTP para responder cargas OLAP (Online Analytical Processing) sem derreter o sistema ou os custos do servidor.
O Problema: Linhas vs Colunas
No PostgreSQL, os dados repousam fisicamente orientados à linha. Diante de uma query simples como SUM(faturamento) varrendo 50 milhões de vendas brutas, o motor precisa carregar todos os blocos do disco com informações totalmente desnecessárias naquele momento (descrições gigantes de cliente, blobs secundários, metadados irrelevantes) para chegar à extração física daquela única coluna de soma.
Isso resulta num gargalo terrível de saturação de I/O de disco. Os caches da RAM da máquina são substituídos para dar lugar ao sequencial scan gigantesco, o que imediatamente causa colapso na latência das tarefas transacionais (o simples “fazer login no app” fica lento).
A Abordagem da Montinegro Analytics: Separação de Responsabilidades
Para garantir processamento sub-segundo aos relatórios vitais dos nossos clientes B2B independentemente de volume de dados, nós aplicamos estritamente uma arquitetura altamente bifurcada e tolerante a falhas.
1. PostgreSQL (A Fonte Verdadeira Transacional)
Utilizamos o PostgreSQL estrita e exclusivamente para ser o coração transacional de nossos sistemas. Mantém os usuários do tenant logados, gerencia a autorização REST da API e as preferências da aplicação SaaS. Dessa forma, sua resposta média se restringe a requisições curtas batendo 10ms-20ms de latência do ORM Django.
2. ClickHouse (A Âncora Analítica)
Todos os fluxos em massa — eventos pesados, biometria de infraestrutura em nuvem (ex: métricas estranguladas de processamento PBIX), logs estruturados e BI dimensional bruto — deságuam sob responsabilidade do ClickHouse, um ultra veloz banco orientado a colunas desenvolvido na Rússia e hoje soberano na extração OLAP moderna.
Pela sua mecânica de blocos isolados por eixo horizontal, um select nas colunas alvo ignora o ruído envolvente. A mesma query sobre bilhões de dados devolve agregações sob índices em tempo relacional minúsculo.
3. Celery & Redis (A Ingestão Assíncrona Bufferizada)
Para preencher toda a barragem de dados do ClickHouse sem travar o front do aplicativo, orquestramos tudo delegando Background Jobs. O Django orquestra envios para o Redis, o qual delega execuções intensas aos workers multi-processo do Celery. Se precisamos extrair 30GB de rastreamento do backend do Microsoft Fabric via endpoints .pbip de noite, essas filas quebram e distribuem uniformemente a ingestão mastigada no ClickHouse.
O Consumo Visual Final (Apache Superset)
Somente por cima desse lago de dados colossal que injetamos as camadas de “painel de bordo”. Painéis em Apache Superset (ou futuras instâncias headless acopladas ao Cube.dev) leem o ClickHouse com extrema agressividade via conexões SQL abertas.
A arquitetura final respira sem conflitos: o painel principal voa renderizando gráficos gigantescos, enquanto do outro lado a interface nativa do Flutter e as ações em tempo real do sistema rodam perfeitamente polidas via Python/PostgreSQL limitando zero de banda. Isso é escalabilidade real sem artifícios vazios.