Pular para o conteúdo
Voltar para serviços

Bancos de dados

Bancos de dados rápidos, seguros e explicados

O banco de dados costuma ser o primeiro a ficar curto quando um projeto cresce. Escolher bem, configurá-lo de acordo com o servidor e organizar as tabelas grandes faz a diferença entre uma página que voa e uma que se arrasta.

Deslize o diagrama para ver inteiro

◆tiendaPHP⬢apiAdonisJS⌕Pedidos de outubroWHERE creado >= '2026-10-01'◫pedidos1.000.000+ linhas▤pedidos_2026_07não é lida▤pedidos_2026_08não é lida▤pedidos_2026_09não é lida▤pedidos_2026_10lida
  • Consultas dos aplicativos
  • Só a partição necessária é lida

Uma tabela de pedidos com mais de um milhão de linhas, dividida por meses. Quando a loja ou a API pedem os pedidos de outubro, o PostgreSQL só lê a partição de outubro e deixa as outras de lado: menos disco, menos memória e respostas mais rápidas.

MariaDB ou PostgreSQL, prontos

Ao conectar um servidor você escolhe o banco de dados e o SERVILINUX o instala com a versão do seu sistema, escutando só dentro do servidor.

Compartilhado com seus outros servidores, sem abrir para o mundo

Se um aplicativo de outro servidor precisa do banco, você abre a porta só para esse IP com o firewall do painel.

Monitorado pelo Sentinel

Conexões, consultas por segundo, cache e uso de disco do MariaDB e do PostgreSQL, com alertas e histórico.

A Eisac ajuda a otimizar

Pergunte como ajustar a configuração à memória do servidor, quais índices faltam ou como dividir uma tabela que não para de crescer. Ela explica cada mudança antes de aplicar.

Conversa de exemplo
Meu servidor tem 16 GB de RAM e disco SSD. Como otimizo o PostgreSQL para uma tabela de pedidos com mais de um milhão de linhas que consultamos principalmente por mês?
Eisac

Primeiro, a memória. Com 16 GB e o banco de dados como serviço principal, este é um bom ponto de partida:

# /etc/postgresql/17/main/conf.d/servilinux.conf
# 16 GB de RAM, disco SSD
shared_buffers = 4GB
effective_cache_size = 12GB
work_mem = 32MB
maintenance_work_mem = 1GB
random_page_cost = 1.1
effective_io_concurrency = 200

Depois, divida a tabela por meses. Assim cada consulta lê só o mês de que precisa e arquivar meses antigos é imediato:

CREATE TABLE pedidos (
  id          bigserial,
  creado      timestamptz NOT NULL,
  cliente_id  bigint NOT NULL,
  total       numeric(12,2),
  PRIMARY KEY (id, creado)
) PARTITION BY RANGE (creado);

CREATE TABLE pedidos_2026_10 PARTITION OF pedidos
  FOR VALUES FROM ('2026-10-01') TO ('2026-11-01');

CREATE INDEX ON pedidos (cliente_id, creado);

Crie a partição de cada mês antes de ele começar; você pode agendar uma tarefa que faça isso sozinha. Se os aplicativos também rodam no servidor, baixe shared_buffers para 3 GB. Quer que eu revise antes as consultas mais lentas?

Em breve no painel: criar bancos e usuários com senhas que nunca trafegam em texto puro, backups agendados com restauração e acesso seguro pelo DBeaver ou TablePlus.

No SERVILINUX

Como se faz

  1. 1
    Escolha seu banco de dados

    MariaDB ou PostgreSQL ao conectar o servidor.

  2. 2
    Conecte seu projeto

    Coloque os dados de conexão nas variáveis do projeto.

  3. 3
    Ative no Sentinel

    As métricas e alertas aparecem junto às do servidor.

  4. 4
    Otimize com a Eisac

    Configuração, índices e partições explicados passo a passo.