O que é banco de dados: tipos, SGBD, exemplos e como escolher

Banco de dados (ou base de dados) é um conjunto organizado de informações, guardado de um jeito que um programa consegue consultar, alterar e cruzar rapidamente: o cadastro de clientes de uma loja, os posts de um blog, o estoque de um ERP. Quem cuida dele é um SGBD (sistema de gerenciamento de banco de dados), como MySQL, PostgreSQL ou MongoDB.

Se você tem um site, um sistema de gestão ou um aplicativo, já usa banco de dados, mesmo sem nunca ter aberto um. Entender o básico ajuda a escolher a hospedagem certa, conversar com quem desenvolve o sistema e, principalmente, não perder informação.

---

O que é banco de dados

Pense numa planilha de clientes. Ela funciona bem com 200 linhas e uma pessoa editando. Agora imagine 2 milhões de linhas, cinquenta pessoas e um site gravando pedidos ao mesmo tempo, e você precisando saber em menos de um segundo quais clientes de Curitiba compraram no último mês. É para isso que existe o banco de dados: guardar muita informação estruturada e responder perguntas sobre ela com rapidez e segurança.

Alguns exemplos que você provavelmente usa:

• um site em WordPress guarda posts, páginas, usuários e configurações num banco MySQL ou MariaDB;
• uma loja virtual registra produtos, estoque, carrinhos e pedidos;
• o ERP da empresa mantém notas fiscais, contas a pagar e cadastro de fornecedores;
• o aplicativo do banco mostra seu saldo consultando, a cada acesso, o banco de dados da instituição.

Banco de dados, SGBD e “sistema de dados”: o banco é o conjunto de informações; o SGBD é o software que o gerencia. No dia a dia as duas coisas viram sinônimo (“o banco é MySQL”), e expressões como “sistema de dados” ou “sistema de gestão de base de dados” (termo comum em Portugal) costumam se referir ao SGBD. Já os arquivos onde tudo isso fica gravado são assunto de armazenamento de dados.

---

O que faz um SGBD

O sistema de gerenciamento de banco de dados fica entre os aplicativos e os arquivos gravados em disco. O site não abre esses arquivos diretamente: ele pede ao SGBD “me traga os 10 últimos pedidos” e o SGBD descobre a forma mais rápida de responder. No caminho, ele cuida de várias tarefas que você teria de resolver na mão com planilhas:

• Consultas: interpreta o pedido (em SQL, no caso dos bancos relacionais) e escolhe o melhor plano para buscá-lo.
• Transações: garante que operações em várias etapas aconteçam por inteiro ou não aconteçam. Se a baixa no estoque falhar, o pedido também não é gravado.
• Acesso simultâneo: deixa centenas de usuários lerem e gravarem ao mesmo tempo sem um sobrescrever o outro.
• Permissões: define quem pode ler, alterar ou apagar cada tabela.
• Recuperação: registra as alterações num log para voltar a um estado consistente depois de uma queda de energia, além de oferecer ferramentas de cópia e replicação.

---

Banco relacional × não relacional

Os bancos relacionais organizam tudo em tabelas com colunas definidas e ligam uma tabela à outra por chaves. Usam SQL e são a escolha padrão para sistemas de gestão, lojas e quase todo site. Os não relacionais (chamados de NoSQL) abrem mão desse formato rígido em troca de flexibilidade ou velocidade em casos específicos: documentos com estrutura variável, cache em memória, grafos de relacionamento.

Modelo	Como organiza	Exemplos	Bom para
Relacional	Tabelas com linhas e colunas, ligadas por chaves; consulta em SQL	MySQL, MariaDB, PostgreSQL, Microsoft SQL Server, Oracle Database, SQLite	Sites, lojas, ERPs, financeiro, qualquer dado que precisa de consistência
Documento	Documentos no formato JSON, cada um podendo ter campos diferentes	MongoDB	Catálogos com atributos variados, aplicativos que mudam de estrutura com frequência
Chave-valor em memória	Pares chave e valor, mantidos na RAM	Redis, Valkey	Cache, sessões de usuário, filas, contadores em tempo real
Colunar distribuído	Linhas agrupadas por chave e espalhadas por vários servidores	Apache Cassandra	Gravação de volumes enormes, como telemetria e eventos
Grafo	Nós e as relações entre eles	Neo4j	Redes sociais, recomendações, detecção de fraude

Uma observação sobre licenças, que mudaram bastante nos últimos anos. MySQL e MariaDB têm versões gratuitas de código aberto; o PostgreSQL usa uma licença própria bem permissiva; o SQL Server é comercial, com uma edição Express gratuita e limitada. O MongoDB Community usa a licença SSPL. O Redis passou a ser oferecido, a partir da versão 8, sob três licenças à escolha do usuário, entre elas a AGPLv3, conforme a página de licenças do Redis. O Valkey é um fork do Redis mantido sob a Linux Foundation, com licença BSD.

Na prática: muitos projetos usam os dois tipos juntos. Uma loja pode guardar pedidos no MySQL e usar o Redis como cache para não consultar o banco principal a cada página aberta.

---

Conceitos básicos: tabela, registro, chave, índice e SQL

Meia dúzia de termos explica quase tudo o que aparece num banco relacional:

• Tabela: o conjunto de dados de um mesmo assunto, como clientes ou pedidos.
• Registro (linha): um item da tabela, por exemplo um cliente.
• Coluna (campo): uma característica do registro, com tipo definido: nome é texto, total é número decimal, data é data.
• Chave primária: a coluna que identifica cada registro sem repetição, geralmente um número sequencial.
• Chave estrangeira: a coluna que aponta para outra tabela. O pedido guarda o id do cliente, e não o nome dele repetido.
• Índice: uma estrutura auxiliar que acelera buscas por uma coluna, como o índice remissivo de um livro. Custa um pouco de espaço e deixa as gravações um pouco mais lentas.
• Consulta SQL: o comando que você envia ao banco para criar, inserir, alterar ou buscar dados.

Veja tudo isso junto num exemplo em SQL, na sintaxe do MySQL e do MariaDB. Primeiro, duas tabelas ligadas por chave estrangeira e um índice na data do pedido:

CREATE TABLE clientes (
  id INT AUTO_INCREMENT PRIMARY KEY,
  nome VARCHAR(100) NOT NULL,
  email VARCHAR(150) UNIQUE,
  cidade VARCHAR(60)
);

CREATE TABLE pedidos (
  id INT AUTO_INCREMENT PRIMARY KEY,
  cliente_id INT NOT NULL,
  total DECIMAL(10,2) NOT NULL,
  criado_em DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (cliente_id) REFERENCES clientes(id)
);

CREATE INDEX idx_pedidos_criado_em ON pedidos (criado_em);

Depois, uma consulta que responde a uma pergunta de negócio: quais os dez clientes que mais compraram em 2026?

SELECT c.nome, COUNT(p.id) AS pedidos, SUM(p.total) AS faturamento
FROM clientes c
JOIN pedidos p ON p.cliente_id = c.id
WHERE p.criado_em >= '2026-01-01'
GROUP BY c.id, c.nome
ORDER BY faturamento DESC
LIMIT 10;

O JOIN junta as duas tabelas pela chave, o WHERE filtra o período (e usa o índice para não varrer todos os pedidos) e o GROUP BY soma tudo por cliente. Se quiser ir além, o nosso guia sobre o que é MySQL mostra como esse SGBD funciona na hospedagem de sites.

---

Banco gerenciado × no próprio servidor

Escolhido o SGBD, falta decidir onde ele vai rodar. São três caminhos comuns, e a diferença está em quem faz o trabalho de manutenção:

	Hospedagem compartilhada com cPanel	No próprio servidor (VPS ou dedicado)	Banco gerenciado (DBaaS)
Exemplo	Bancos MySQL criados pelo painel da hospedagem	MySQL, PostgreSQL ou outro instalado por você num servidor com acesso root	Amazon RDS, Azure SQL Database, Google Cloud SQL
Quem instala e atualiza	O provedor	Você ou sua equipe	O provedor de nuvem
Controle de configuração	Baixo	Total	Médio, dentro das opções do serviço
Escolha do SGBD	O que o painel oferece	Qualquer um	Os que o serviço suporta
Faz sentido para	Sites, blogs e lojas de pequeno e médio porte	Sistemas sob medida, vários bancos, ajuste fino de desempenho	Aplicações já na mesma nuvem, equipes sem DBA

Quem vai para um servidor próprio precisa dimensionar os recursos. Os bancos relacionais adoram memória: quanto mais dados cabem na RAM, menos leitura em disco. Disco SSD, de preferência NVMe, faz diferença nas muitas leituras pequenas que um banco faz. A CPU pesa mais quando há muitas consultas complexas ao mesmo tempo. A melhor referência é medir o uso real por algumas semanas antes de aumentar ou reduzir o plano.

Na SAN: a Hospedagem de Sites vem com cPanel, onde você cria bancos MySQL e usuários pelo painel. Quando o projeto pede acesso root e ajuste fino do banco, o Cloud Server oferece SSD, root e cPanel/WHM.

---

Boas práticas: backup, permissões e atualização

A maioria dos desastres com banco de dados não vem de ataques sofisticados, e sim de descuidos simples. Estas cinco medidas resolvem boa parte deles:

1. Backup automático, fora do servidor e testado. Faça cópias diárias, guarde várias versões e mantenha pelo menos uma em outro lugar, como um backup na nuvem. De tempos em tempos, restaure uma cópia num ambiente de teste para conferir se ela funciona.
2. Um usuário por aplicação, com o mínimo de permissão. O site precisa ler e gravar nas suas tabelas, não apagar o banco inteiro nem acessar os bancos de outros sistemas. Nunca use o usuário root na aplicação.
3. Banco fechado para a internet. A porta do MySQL (3306) ou do PostgreSQL (5432) não deve ficar aberta para o mundo. Libere só para o servidor da aplicação ou acesse por túnel SSH ou VPN.
4. Versão com suporte. Acompanhe o ciclo de vida do seu SGBD e planeje as migrações com antecedência.
5. Cuidado com dados pessoais. Guarde só o que precisa, restrinja quem consulta e criptografe o que for sensível. Cadastros de clientes estão sujeitos à LGPD.

Ainda usa MySQL 8.0? Essa versão chegou ao fim de vida em abril de 2026 e não recebe mais correções de segurança da comunidade. A Oracle recomenda migrar para as versões LTS 8.4 ou 9.7, conforme o aviso oficial de fim de vida do MySQL. Teste o sistema numa cópia antes de atualizar a produção.

---

Como escolher o banco de dados

Na maior parte dos casos, a escolha já vem feita pelo software que você vai usar. O WordPress, por exemplo, trabalha com MySQL ou MariaDB. Quando você tem liberdade para escolher, siga esta ordem:

1. Veja o que o sistema exige. Plataforma pronta, ERP ou CMS costumam suportar um ou dois SGBDs. Não brigue com isso.
2. Olhe para os dados. Se eles têm estrutura clara e relações entre si (clientes, pedidos, produtos), comece por um relacional. Documentos com formato muito variável apontam para um banco de documentos.
3. Pense na consistência. Dinheiro, estoque e notas fiscais pedem transações confiáveis, ponto forte dos relacionais.
4. Considere quem vai manter. Um SGBD que sua equipe ou seu fornecedor já conhece vale mais do que um tecnicamente superior que ninguém sabe operar.
5. Some licença e infraestrutura. MySQL, MariaDB e PostgreSQL não cobram licença; SQL Server e Oracle Database, nas edições completas, sim.
6. Adicione peças só quando precisar. Redis para cache, um banco de documentos para um módulo específico: comece simples e acrescente quando um problema real aparecer.

Para um site, um blog ou uma loja de pequeno e médio porte, MySQL ou MariaDB numa hospedagem com cPanel resolvem sem complicação. Sistemas próprios com regras de negócio mais pesadas costumam ir bem com PostgreSQL num servidor dedicado ao projeto.

---

Perguntas frequentes