Estou a frequentar uma disciplina de cloud Neste...

Claro. Pensa assim:

MySQL/PostgreSQL = base de dados relacional, orientada a relações e SQL.
DynamoDB = base de dados NoSQL gerida pela AWS, orientada a acesso rápido por chave e escala automática.

1. A diferença principal

Numa base de dados relacional, como PostgreSQL/MySQL, normalmente modelas o mundo em várias tabelas ligadas entre si:

text
users
orders
order_items
products

Depois fazes queries com SQL:

sql
SELECT *
FROM orders
JOIN users ON orders.user_id = users.id
WHERE users.email = '[email protected]';

Ou seja, primeiro desenhas o modelo normalizado e depois fazes queries flexíveis com SELECT, JOIN, WHERE, agregações, etc.

No DynamoDB, a lógica é diferente. Tens tabelas, mas cada tabela contém items e cada item tem attributes. A AWS descreve estes como os componentes centrais do DynamoDB: table, item e attributes. Cada item é identificado por uma primary key, normalmente uma partition key e, opcionalmente, uma sort key. (AWS Documentation)

---

2. O DynamoDB não é “SQL com sintaxe diferente”

Esta é a parte mais importante para perceberes a aula.

Em SQL, perguntas:

“Que dados quero consultar?”

Em DynamoDB, perguntas primeiro:

“Como é que a minha aplicação vai aceder aos dados?”

Isto chama-se modelar pelos access patterns.

Exemplo: imagina uma app de encomendas.

Em PostgreSQL poderias ter:

text
users(id, name, email)
orders(id, user_id, date, status)
products(id, name, price)
order_items(order_id, product_id, quantity)

Em DynamoDB poderias pensar antes nas perguntas da app:

text
1. Quero buscar o utilizador pelo id.
2. Quero listar encomendas de um utilizador.
3. Quero ver detalhes de uma encomenda.
4. Quero listar encomendas por estado.

Depois escolhes chaves que tornem essas leituras rápidas.

Por exemplo:

text
Table: AppData

PK = USER#123
SK = PROFILE

PK = USER#123
SK = ORDER#2026-05-19#987

PK = ORDER#987
SK = DETAILS

Aqui, em vez de fazeres JOIN, organizas os dados para ires buscar diretamente aquilo que a aplicação precisa. A própria documentação da AWS compara o design relacional com o design NoSQL e realça que em DynamoDB o modelo deve ser pensado para os padrões de acesso da aplicação. (AWS Documentation)

---

3. Schema rígido vs schema flexível

Em PostgreSQL/MySQL, normalmente defines o schema completo:

sql
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100),
  email VARCHAR(100) UNIQUE
);

Todos os registos seguem aquela estrutura.

Em DynamoDB, a tabela é muito mais flexível. Tens de definir a chave primária, mas os outros atributos podem variar de item para item. A AWS descreve as tabelas DynamoDB como “schemaless” exceto pela primary key. (AWS Documentation)

Exemplo:

json
{
  "PK": "USER#123",
  "SK": "PROFILE",
  "name": "Ana",
  "email": "[email protected]"
}

Outro item na mesma tabela pode ter campos diferentes:

json
{
  "PK": "USER#123",
  "SK": "ORDER#987",
  "total": 49.99,
  "status": "PAID",
  "createdAt": "2026-05-19"
}

Isto parece estranho vindo de SQL, porque metes “tipos de coisas diferentes” na mesma tabela. Mas em DynamoDB isso é comum.

---

4. JOINs: aqui muda muito

Em SQL, JOIN é normal:

sql
SELECT users.name, orders.total
FROM users
JOIN orders ON users.id = orders.user_id;

Em DynamoDB, deves evitar depender de joins. Normalmente fazes uma destas coisas:

1. Guardas os dados já juntos, duplicando alguma informação.

json
{
  "PK": "USER#123",
  "SK": "ORDER#987",
  "userName": "Ana",
  "total": 49.99
}

2. Fazes duas leituras pela chave, se precisares mesmo.

3. Desenhas a chave para conseguires obter tudo com uma query eficiente.

Isto é uma mudança mental grande: em bases relacionais tentas evitar duplicação; em DynamoDB, alguma duplicação pode ser aceitável para ganhar velocidade e escala.

A documentação da AWS também refere que relações podem existir em DynamoDB, mas são modeladas de forma diferente das bases relacionais e das foreign keys tradicionais. (AWS Documentation)

---

5. Query vs Scan

Em PostgreSQL/MySQL, podes escrever muitos tipos de SELECT.

Em DynamoDB tens operações como:

text
GetItem  -> buscar um item pela chave
Query    -> buscar items com uma partition key, e talvez filtrar/ordenar pela sort key
Scan     -> varrer a tabela inteira

A ideia é usares GetItem e Query sempre que possível. Scan é parecido com “ler a tabela toda”, por isso pode ficar caro e lento em tabelas grandes. A documentação da AWS distingue estas operações quando compara SQL com DynamoDB. (AWS Documentation)

Exemplo bom em DynamoDB:

text
Dá-me todas as encomendas do USER#123.

Se a partition key for USER#123, isto é eficiente.

Exemplo mau:

text
Dá-me todos os utilizadores cujo nome começa por Ana,
mas eu não criei índice nenhum para isso.

Isto provavelmente obriga a Scan ou a criar um índice adequado.

---

6. O que significa ser “orientado a cloud”?

Aqui está o ponto essencial da aula.

Numa base de dados tradicional, muitas vezes pensas em:

text
Servidor
CPU
RAM
Disco
Instalação
Backups
Patching
Escala vertical
Administração

Em DynamoDB pensas mais em:

text
Tabela
Chaves
Capacidade de leitura/escrita
Latência
Escalabilidade
Custo por pedido
Permissões IAM
Integração com outros serviços AWS

DynamoDB é um serviço fully managed da AWS. A AWS trata da infraestrutura por baixo. A documentação oficial descreve-o como uma base NoSQL totalmente gerida, com performance previsível e escalabilidade automática/seamless. (AWS Documentation)

Ou seja, em vez de instalares PostgreSQL num servidor, configurares disco, réplica, backups e updates, estás a usar um serviço cloud pronto a escalar.

---

7. Escalabilidade: uma grande razão para existir DynamoDB

DynamoDB foi pensado para workloads com muitos pedidos e crescimento grande.

Em SQL relacional, se a carga aumenta muito, podes precisar de:

text
Aumentar máquina
Criar réplicas
Particionar dados
Fazer sharding
Otimizar índices
Gerir conexões

Em DynamoDB, a AWS dá-te modos de capacidade. No modo on-demand, pagas por pedidos de leitura/escrita e não tens de planear capacidade antecipadamente. No modo provisioned, defines a capacidade de leitura e escrita esperada. (AWS Documentation)

Isto encaixa muito bem em cloud porque podes ter uma app que hoje tem pouco tráfego, amanhã tem um pico enorme, e queres que a base de dados aguente sem teres de gerir servidores manualmente.

---

8. Comparação rápida

Conceito	PostgreSQL/MySQL	DynamoDB
Tipo	Relacional / SQL	NoSQL, key-value/document
Schema	Normalmente rígido	Flexível, exceto chaves
Query	SQL poderoso	GetItem, Query, Scan
JOINs	Normais	Evitados; modelas dados de outra forma
Escala	Muitas vezes exige gestão/arquitetura extra	Pensado para escala gerida pela AWS
Modelo mental	Normalização e relações	Access patterns e chaves
Bom para	Dados relacionais complexos, relatórios, transações SQL	Alta escala, baixa latência, acessos previsíveis
Gestão	Tens mais controlo, mas mais trabalho	AWS gere grande parte da infraestrutura

---

9. Exemplo mental muito simples

Imagina que tens uma app tipo carrinho de compras.

Em PostgreSQL

Pensas:

text
Tenho users, carts, products, cart_items.
Vou relacionar tudo com foreign keys.

Depois consultas com joins.

Em DynamoDB

Pensas:

text
Quando um utilizador abre a app, preciso de ir buscar rapidamente o carrinho dele.

Então podes guardar os dados assim:

text
PK = USER#123
SK = CART#ACTIVE
items = [
  { productId: "P1", name: "Teclado", qty: 1 },
  { productId: "P2", name: "Rato", qty: 2 }
]

Com uma leitura pela chave, tens logo o carrinho. Não precisas de fazer join entre 4 tabelas.

---

10. Quando usar cada um?

Usa PostgreSQL/MySQL/RDS/Aurora quando tens:

text
Relações complexas
Muitos joins
Consultas SQL flexíveis
Relatórios
Transações complexas
Consistência relacional forte

Usa DynamoDB quando tens:

text
Acessos muito previsíveis
Muitas leituras/escritas por chave
Baixa latência
Escala grande
Apps serverless
Eventos, sessões, carrinhos, perfis, IoT, jogos, logs operacionais

O erro comum é pensar: “DynamoDB é melhor que PostgreSQL”. Não é bem assim. É melhor para certos padrões cloud, principalmente quando sabes bem como a aplicação vai aceder aos dados.

---

Frase para memorizares

Numa base relacional, modelas os dados pela sua estrutura.
Em DynamoDB, modelas os dados pela forma como a aplicação os vai consultar.

Essa é provavelmente a maior diferença para acompanhares a aula.