Pular para o conteúdo principal
ClickHouse Managed Postgres é um Postgres de nível empresarial com armazenamento NVMe, oferecendo desempenho até 10x superior para cargas de trabalho limitadas por disco em comparação com armazenamento conectado à rede, como o EBS. Este guia de início rápido está dividido em duas partes:
  • Parte 1: Comece a usar o NVMe Postgres e veja seu desempenho na prática
  • Parte 2: Habilite analytics em tempo real integrando-o ao ClickHouse
No momento, o Managed Postgres está disponível na AWS em várias regiões e é gratuito durante a prévia privada. Neste guia de início rápido, você irá:
  • Criar uma instância de Managed Postgres com desempenho impulsionado por NVMe
  • Carregar 1 milhão de eventos de exemplo e ver a velocidade do NVMe em ação
  • Executar consultas e experimentar baixa latência
  • Replicar dados para o ClickHouse para analytics em tempo real
  • Consultar o ClickHouse diretamente do Postgres usando pg_clickhouse

Parte 1: Primeiros passos com o NVMe Postgres

Criar um banco de dados

Para criar um novo serviço Managed Postgres, clique no botão Novo serviço na lista de serviços do Cloud Console. Em seguida, você poderá selecionar Postgres como tipo de banco de dados. Digite um nome para a instância do banco de dados e clique em Criar serviço. Você será direcionado para a página Overview. Sua instância do Managed Postgres será provisionada e estará pronta para uso em 3 a 5 minutos.

Conecte-se ao seu banco de dados

Na barra lateral esquerda, você verá um botão Connect. Clique nele para ver os detalhes da conexão e as strings de conexão em vários formatos. Copie a string de conexão do psql e conecte-se ao seu banco de dados. Você também pode usar qualquer cliente compatível com Postgres, como o DBeaver, ou qualquer biblioteca de aplicativo.

Experimente o desempenho com NVMe

Vamos ver na prática o desempenho proporcionado pelo NVMe. Primeiro, ative a temporização no psql para medir a execução da consulta:
\timing
Crie duas tabelas de exemplo para eventos e usuários:
CREATE TABLE events (
   event_id SERIAL PRIMARY KEY,
   event_name VARCHAR(255) NOT NULL,
   event_type VARCHAR(100),
   event_timestamp TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
   event_data JSONB,
   user_id INT,
   user_ip INET,
   is_active BOOLEAN DEFAULT TRUE,
   created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
   updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE users (
   user_id SERIAL PRIMARY KEY,
   name VARCHAR(100),
   country VARCHAR(50),
   platform VARCHAR(50)
);
Agora, insira 1 milhão de eventos e veja a velocidade do NVMe:
INSERT INTO events (event_name, event_type, event_timestamp, event_data, user_id, user_ip)
SELECT
   'Event ' || gs::text AS event_name,
   CASE
       WHEN random() < 0.5 THEN 'click'
       WHEN random() < 0.75 THEN 'view'
       WHEN random() < 0.9 THEN 'purchase'
       WHEN random() < 0.98 THEN 'signup'
       ELSE 'logout'
   END AS event_type,
   NOW() - INTERVAL '1 day' * (gs % 365) AS event_timestamp,
   jsonb_build_object('key', 'value' || gs::text, 'additional_info', 'info_' || (gs % 100)::text) AS event_data,
   GREATEST(1, LEAST(1000, FLOOR(POWER(random(), 2) * 1000) + 1)) AS user_id,
   ('192.168.1.' || ((gs % 254) + 1))::inet AS user_ip
FROM
   generate_series(1, 1000000) gs;
INSERT 0 1000000
Time: 3596.542 ms (00:03.597)
Desempenho do NVMe1 milhão de linhas com dados JSONB inseridas em menos de 4 segundos. Em bancos de dados em nuvem tradicionais que usam armazenamento conectado à rede, como EBS, essa mesma operação normalmente leva de 2 a 3 vezes mais tempo devido à latência de ida e volta da rede e à limitação de IOPS. O armazenamento NVMe elimina esses gargalos ao manter o armazenamento fisicamente conectado ao compute.O desempenho varia de acordo com o tamanho da instância, a carga atual e as características dos dados.
Insira 1.000 usuários:
INSERT INTO users (name, country, platform)
SELECT
    first_names[first_idx] || ' ' || last_names[last_idx] AS name,
    CASE
        WHEN random() < 0.25 THEN 'India'
        WHEN random() < 0.5 THEN 'USA'
        WHEN random() < 0.7 THEN 'Germany'
        WHEN random() < 0.85 THEN 'China'
        ELSE 'Other'
    END AS country,
    CASE
        WHEN random() < 0.2 THEN 'iOS'
        WHEN random() < 0.4 THEN 'Android'
        WHEN random() < 0.6 THEN 'Web'
        WHEN random() < 0.75 THEN 'Windows'
        WHEN random() < 0.9 THEN 'MacOS'
        ELSE 'Linux'
    END AS platform
FROM
    generate_series(1, 1000) AS seq
    CROSS JOIN LATERAL (
        SELECT
            array['Alice', 'Bob', 'Charlie', 'Diana', 'Eve', 'Frank', 'Grace', 'Hank', 'Ivy', 'Jack', 'Liam', 'Olivia', 'Noah', 'Emma', 'Sophia', 'Benjamin', 'Isabella', 'Lucas', 'Mia', 'Amelia', 'Aarav', 'Riya', 'Arjun', 'Ananya', 'Wei', 'Li', 'Huan', 'Mei', 'Hans', 'Klaus', 'Greta', 'Sofia'] AS first_names,
            array['Smith', 'Johnson', 'Williams', 'Brown', 'Jones', 'Garcia', 'Miller', 'Davis', 'Martinez', 'Taylor', 'Anderson', 'Thomas', 'Jackson', 'White', 'Harris', 'Martin', 'Thompson', 'Moore', 'Lee', 'Perez', 'Sharma', 'Patel', 'Gupta', 'Reddy', 'Zhang', 'Wang', 'Chen', 'Liu', 'Schmidt', 'Müller', 'Weber', 'Fischer'] AS last_names,
            1 + (seq % 32) AS first_idx,
            1 + ((seq / 32)::int % 32) AS last_idx
    ) AS names;

Execute consultas nos seus dados

Agora vamos executar algumas consultas para ver com que rapidez o Postgres responde com armazenamento NVMe. Agregue 1 milhão de eventos por tipo:
SELECT event_type, COUNT(*) as count 
FROM events 
GROUP BY event_type 
ORDER BY count DESC;
 event_type | count  
------------+--------
 click      | 499523
 view       | 375644
 purchase   | 112473
 signup     |  12117
 logout     |    243
(5 rows)

Time: 114.883 ms
Consulta com filtragem em JSONB e intervalo de datas:
SELECT COUNT(*) 
FROM events 
WHERE event_timestamp > NOW() - INTERVAL '30 days'
  AND event_data->>'additional_info' LIKE 'info_5%';
 count 
-------
  9042
(1 row)

Time: 109.294 ms
Faça JOIN entre eventos e usuários:
SELECT u.country, COUNT(*) as events, AVG(LENGTH(e.event_data::text))::int as avg_json_size
FROM events e
JOIN users u ON e.user_id = u.user_id
GROUP BY u.country
ORDER BY events DESC;
 country | events | avg_json_size 
---------+--------+---------------
 USA     | 383748 |            52
 India   | 255990 |            52
 Germany | 223781 |            52
 China   | 127754 |            52
 Other   |   8727 |            52
(5 rows)

Time: 224.670 ms
Seu Postgres está prontoNeste ponto, você já tem um banco de dados Postgres totalmente funcional e de alto desempenho, pronto para suas cargas de trabalho transacionais.Continue para a Parte 2 para ver como a integração nativa com ClickHouse pode potencializar suas análises.

Parte 2: Adicione analytics em tempo real com ClickHouse

Embora o Postgres se destaque em cargas de trabalho transacionais (OLTP), o ClickHouse foi desenvolvido especificamente para consultas analíticas (OLAP) em grandes volumes de dados. Ao integrar os dois, você obtém o melhor dos dois mundos:
  • Postgres para os dados transacionais da sua aplicação (inserções, atualizações, consultas pontuais)
  • ClickHouse para analytics em tempo real com latência de subsegundo em bilhões de linhas
Esta seção mostra como replicar seus dados do Postgres para o ClickHouse e consultá-los de forma transparente.

Configurar a integração do ClickHouse

Agora que temos tabelas e dados no Postgres, vamos replicar as tabelas para o ClickHouse para fins analíticos. Começamos clicando em ClickHouse integration na barra lateral. Em seguida, clique em Replicate data in ClickHouse. No formulário a seguir, você pode inserir um nome para a integração e selecionar uma instância existente do ClickHouse para a qual os dados serão replicados. Se você ainda não tiver uma instância do ClickHouse, poderá criar uma diretamente nesse formulário.
ImportanteCertifique-se de que o serviço do ClickHouse selecionado esteja Running antes de prosseguir.
Clique em Next para ir ao seletor de tabelas. Aqui, tudo o que você precisa fazer é:
  • Selecionar um banco de dados do ClickHouse para o qual replicar.
  • Expandir o esquema public e selecionar as tabelas users e events que criamos anteriormente.
  • Clicar em Replicate data to ClickHouse.
O processo de replicação será iniciado, e você será levado à página de visão geral da integração. Como esta é a primeira integração, a configuração da infraestrutura inicial pode levar de 2 a 3 minutos. Enquanto isso, vamos dar uma olhada na nova extensão pg_clickhouse.

Consulte o ClickHouse a partir do Postgres

A extensão pg_clickhouse permite consultar dados do ClickHouse diretamente no Postgres usando SQL padrão. Isso significa que sua aplicação pode usar o Postgres como uma camada unificada de consultas para dados transacionais e analíticos. Consulte a documentação completa para mais detalhes. Ative a extensão:
CREATE EXTENSION pg_clickhouse;
Em seguida, crie uma conexão de servidor estrangeiro para o ClickHouse. Use o driver http com a porta 8443 para conexões seguras:
CREATE SERVER ch FOREIGN DATA WRAPPER clickhouse_fdw
       OPTIONS(driver 'http', host '<clickhouse_cloud_host>', dbname '<database_name>', port '8443');
Substitua <clickhouse_cloud_host> pelo hostname do seu ClickHouse e <database_name> pelo banco de dados que você selecionou durante a configuração da replicação. Você pode encontrar o hostname no seu serviço do ClickHouse clicando em Connect na barra lateral. Agora, mapeamos o usuário do Postgres para as credenciais do serviço do ClickHouse:
CREATE USER MAPPING FOR CURRENT_USER SERVER ch 
OPTIONS (user 'default', password '<clickhouse_password>');
Agora importe as tabelas do ClickHouse para um esquema do Postgres:
CREATE SCHEMA organization;
IMPORT FOREIGN SCHEMA "<database_name>" FROM SERVER ch INTO organization;
Substitua <database_name> pelo mesmo nome do banco de dados que você usou ao criar o servidor. Agora você pode ver todas as tabelas do ClickHouse no seu cliente Postgres:
\det+ organization.*

Veja suas análises em ação

Vamos voltar à página da integração. Você deverá ver que a replicação inicial foi concluída. Clique no nome da integração para ver os detalhes. Clique no nome do serviço para abrir o Console do ClickHouse e ver suas tabelas replicadas.

Compare o desempenho entre Postgres e ClickHouse

Agora, vamos executar algumas consultas analíticas e comparar o desempenho entre Postgres e ClickHouse. Observe que as tabelas replicadas usam a convenção de nomenclatura public_<table_name>. Consulta 1: Usuários mais ativos Esta consulta identifica os usuários mais ativos com várias agregações:
-- Via ClickHouse
SELECT 
    user_id,
    COUNT(*) as total_events,
    COUNT(DISTINCT event_type) as unique_event_types,
    SUM(CASE WHEN event_type = 'purchase' THEN 1 ELSE 0 END) as purchases,
    MIN(event_timestamp) as first_event,
    MAX(event_timestamp) as last_event
FROM organization.public_events
GROUP BY user_id
ORDER BY total_events DESC
LIMIT 10;
 user_id | total_events | unique_event_types | purchases |        first_event         |         last_event         
---------+--------------+--------------------+-----------+----------------------------+----------------------------
       1 |        31439 |                  5 |      3551 | 2025-01-22 22:40:45.612281 | 2026-01-21 22:40:45.612281
       2 |        13235 |                  4 |      1492 | 2025-01-22 22:40:45.612281 | 2026-01-21 22:40:45.612281
...
(10 rows)

Time: 163.898 ms   -- ClickHouse
Time: 554.621 ms   -- Mesma consulta no Postgres
Consulta 2: Engajamento dos usuários por país e plataforma Esta consulta combina eventos com usuários e calcula métricas de engajamento:
-- Via ClickHouse
SELECT 
    u.country,
    u.platform,
    COUNT(DISTINCT e.user_id) as users,
    COUNT(*) as total_events,
    ROUND(COUNT(*)::numeric / COUNT(DISTINCT e.user_id), 2) as events_per_user,
    SUM(CASE WHEN e.event_type = 'purchase' THEN 1 ELSE 0 END) as purchases
FROM organization.public_events e
JOIN organization.public_users u ON e.user_id = u.user_id
GROUP BY u.country, u.platform
ORDER BY total_events DESC
LIMIT 10;
 country | platform | users | total_events | events_per_user | purchases 
---------+----------+-------+--------------+-----------------+-----------
 USA     | Android  |   115 |       109977 |             956 |     12388
 USA     | Web      |   108 |       105057 |             972 |     11847
 USA     | iOS      |    83 |        84594 |            1019 |      9565
 Germany | Android  |    85 |        77966 |             917 |      8852
 India   | Android  |    80 |        68095 |             851 |      7724
...
(10 rows)

Time: 170.353 ms   -- ClickHouse
Time: 1245.560 ms  -- Mesma consulta no Postgres
Comparação de desempenho:
ConsultaPostgres (NVMe)ClickHouse (via pg_clickhouse)Ganho
Principais usuários (5 agregações)555 ms164 ms3.4x
Engajamento dos usuários (JOIN + agregações)1,246 ms170 ms7.3x
Quando usar o ClickHouseMesmo neste conjunto de dados de 1 milhão de linhas, o ClickHouse oferece desempenho 3 a 7 vezes superior em consultas analíticas complexas com JOINs e múltiplas agregações. A diferença fica ainda mais expressiva em escalas maiores (100M+ linhas), quando o armazenamento colunar e a execução vetorizada do ClickHouse podem proporcionar ganhos de 10 a 100 vezes.Os tempos de consulta variam de acordo com o tamanho da instância, a latência de rede entre os serviços, as características dos dados e a carga atual.

Limpeza

Para excluir os recursos criados neste quickstart:
  1. Primeiro, exclua a integração do ClickPipe do serviço ClickHouse
  2. Em seguida, exclua a instância do Managed Postgres no Cloud Console
Última modificação em 10 de junho de 2026