DynamoDB를 사용하지 말아야 할 때는 언제인가요?

워크로드가 분석적이거나 접근 패턴을 알 수 없을 때 DynamoDB를 건너뛰세요. DynamoDB는 알려진 키 기반 접근 패턴을 가진 운영(OLTP) 워크로드를 위해 만들어졌습니다 — 조인이나 집계 함수가 없고, 임시 쿼리는 비용이 큰 전체 테이블 스캔으로 되돌아갑니다. OLAP 리포팅이나 진화하는 관계형 요구에는 다른 엔진을 선택하세요.

잘 맞지 않는 경우

임시 분석 및 리포팅(OLAP) — GROUP BY, SUM, AVG가 없습니다. 모든 롤업은 스캔이거나 직접 유지하는 사전 계산된 집계입니다. 우회 방법은 집계 가이드를 참고하세요.
정규화된 관계형 스키마 — DynamoDB는 의도적으로 JOIN 연산자를 생략합니다. AWS 자체의 지침은 비정규화하는 것입니다. 모델이 정말로 읽기 시점의 다방향 조인을 필요로 한다면 관계형 엔진이 더 잘 맞습니다 — DynamoDB vs PostgreSQL에서 직접 비교하세요.
알 수 없거나 빠르게 진화하는 접근 패턴 — 키를 쿼리를 중심으로 설계합니다. 아직 쿼리의 이름을 댈 수 없다면, 새로운 쿼리마다 테이블 재설계나 전체 스캔을 위협합니다.
전문 검색 및 풍부한 쿼리 — DynamoDB는 전문 검색을 지원하나요?를 참고하세요. 검색은 검색 인덱스에 속합니다.
대형 객체 — 항목은 400 KB로 제한됩니다. 미디어와 문서는 테이블에 포인터를 두고 S3에 속합니다.

빛을 발하는 경우

그 반대 목록이 바로 DynamoDB의 최적 지점입니다: 규모와 관계없이 한 자릿수 밀리초를 유지해야 하는 예측 가능한 키 기반 읽기와 쓰기를 가진 대용량 운영 워크로드 — 장바구니, 세션, 프로필, 게임 상태, IoT 이벤트입니다. DynamoDB를 사용해야 할 때 가이드가 긍정적인 사례를 제시하고, DynamoDB vs. 비교가 정면 대결을 안내합니다.

더 알아보기

망설이고 있다면 다음으로 DynamoDB를 사용해야 할 때를 읽어 보세요. 이미 DynamoDB를 사용 중이고 SQL이 그립나요? DynoTable은 데스크톱에서 라이브 테이블에 대해 JOIN과 GROUP BY를 실행합니다 — 그리고 요금 계산기는 확정하기 전에 워크로드의 비용을 알려줍니다.

참고 자료

Last verified 2026-07-13 against the official AWS documentation linked above.