O essencial
pgbench (ferramenta PostgreSQL oficial, carga de trabalho próxima ao TPC-B) e sysbench-tpcc (carga de trabalho TPC-C mais representativa de uma carga transacional real) são executados diretamente na string de conexão Postgres 16 padrão do seu projeto Aurabase - sem API proprietária para ignorar. Este tutorial mostra os pedidos reais e onde termina o que um valor de GST pode provar legitimamente.
pgbench para simplicidade, sysbench-tpcc para realismo
pgbench é distribuído com o próprio PostgreSQL: nenhuma instalação separada no cliente se você já possui ferramentas de cliente Postgres. Sua carga de trabalho padrão reproduz uma carga próxima ao benchmark histórico TPC-B – simples, rápido de iniciar, útil para um primeiro sinal.
sysbench é uma ferramenta de benchmark mais geral, com um plugin sysbench-tpcc que replica a carga de trabalho TPC-C — uma mistura de transações representativas de um aplicativo OLTP real (pedidos, pagamentos, estoque), mais próximo do que seu backend Aurabase lida na produção do que a carga de trabalho genérica do pgbench.
Recuperar a string de conexão e criar uma base de testes dedicada
1
Recuperar a string de conexão do painel Aurabase
Seção de banco de dados do seu projeto, formato postgresql://user:password@host:5432/dbnamepadrão.
2
Crie uma base de testes separada, nunca sua base de produção
psql "$AURABASE_CONN" -c "CRIAR BANCO DE DADOS bench_test;"
pgbench e sysbench-tpcc criam, preenchem e modificam tabelas. Utilize sempre uma base dedicada, nunca um esquema que atenda tráfego real.
Inicialize e inicie uma primeira execução
1
Inicialize o conjunto de dados
pgbench -i -s 10 "postgresql://user:pass@host:5432/bench_test" # -s 10 = fator de escala (10 × 100.000 linhas em pgbench_accounts)
2
Execute uma execução de 60 segundos, 10 clientes concorrentes
pgbench -c 10 -j 2 -T 60 -P 5 "postgresql://user:pass@host:5432/bench_test" # -c = clientes simultâneos · -j = threads · -T = duração em segundos · -P = relatório a cada 5s
3
Leia o resultado
O pgbench exibe um tps (transações por segundo) ao final da execução, com e sem o tempo de conexão. Observe o fator de escala, o número de clientes e a duração por execução — sem esses três parâmetros, o número por si só não significa nada.
Uma carga de trabalho transacional mais representativa
1
Instale o sysbench e o plugin tpcc
git clone https://github.com/Percona-Lab/sysbench-tpcc.git # siga o README do repositório para compilar o plugin
2
Prepare o conjunto de dados TPC-C
./tpcc.lua --pgsql-host=host --pgsql-user=usuário --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 preparar
3
Comece a corrida
./tpcc.lua --pgsql-host=host --pgsql-user=usuário --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 --time=300 --threads=16 --report-interval=10 executar
Um guia de ajuste sysbench-tpcc dedicado ao PostgreSQL foi publicado pela Percona em maio de 2026 — útil para ajustar shared_buffers e work_mem antes de executar uma execução representativa.
O que um número de GST por si só não prova
O tps depende do fator de escala, do número de clientes simultâneos, do hardware subjacente e das configurações do Postgres ativas no momento da execução. Dois valores de tempo obtidos com parâmetros diferentes não são comparáveis, mesmo na mesma base de dados.
Para que seu resultado sirva como uma referência reproduzível, documente sistematicamente: versão do Postgres, fator de escala, número de clientes/threads, duração da execução e a configuração postgresql.conf efetiva. Consulte nossa metodologia de benchmark completa para o protocolo que aplicamos antes de publicar uma figura.
Ajustando o Postgres antes de reiniciar uma execução
Uma execução de benchmark geralmente revela um gargalo antes de qualquer ajuste – conexões saturadas, vácuo automático lento, índice ausente. Nossa lista de verificação de ajuste do Postgres em produção e nosso artigo sobre max_connections sizing cobrem as configurações a serem verificadas antes de reiniciar uma execução.