DynamoDB를 쓰지 말아야 할 때는 언제인가요?

워크로드가 분석적이거나 액세스 패턴을 아직 모른다면 DynamoDB를 쓰지 마세요. DynamoDB는 알려진 키 기반 액세스 패턴을 가진 운영(OLTP) 워크로드를 위해 특별히 만들어졌습니다. 조인도 집계 함수도 없고, 임의 쿼리는 비싼 테이블 전체 스캔으로 떨어집니다. OLAP 리포팅이나 계속 변하는 관계형 요구에는 다른 엔진을 고르세요.

잘 맞지 않는 경우

임의 분석과 리포팅(OLAP) — GROUP BY도 SUM도 AVG도 없습니다. 모든 집계는 스캔이거나 여러분이 직접 유지하는 사전 계산 값입니다. 우회 방법은 집계 가이드를 보세요.
정규화된 관계형 스키마 — DynamoDB는 의도적으로 JOIN 연산자를 제외했으며, AWS의 안내도 비정규화하라는 것입니다.
알 수 없거나 빠르게 변하는 액세스 패턴 — 키는 쿼리를 중심으로 설계합니다. 쿼리를 아직 이름 붙일 수 없다면, 새 쿼리마다 테이블 재설계나 전체 스캔의 위험이 따릅니다.
전문 검색과 풍부한 쿼리 — DynamoDB는 전문 검색을 지원하나요?를 보세요. 검색은 검색 인덱스의 몫입니다.
큰 객체 — 항목은 400 KB에서 상한에 걸립니다. 미디어와 문서는 S3에 두고 테이블에는 포인터를 남기세요.

거부당한 집계, 그리고 값을 매긴 대안

분석 부적합은 취향의 문제가 아닙니다. PartiQL로 그룹화된 개수를 요청하면 그 문장은 무엇을 읽기도 전에 거부됩니다:

SELECT status, COUNT(*) FROM "orders" GROUP BY status

ValidationException: Unsupported clause: GROUP BY
HTTP 400

그룹화를 빼고 단순 합계를 요청하면 한 단계 더 앞, 파서에서 실패합니다:

SELECT COUNT(*) FROM "orders"

ValidationException: Unexpected path component at 1:8:5
HTTP 400

이 방언에서 COUNT는 함수가 아예 아니므로, 파서는 그것을 속성 경로로 읽다가 괄호에서 포기합니다.

그러면 남는 것은 여러분이 직접 작성하는 Scan이고, 여기에는 값이 붙습니다. 50 GB 테이블을 끝에서 끝까지 읽으면 최종적 일관성 읽기 단위 6,553,600개가 드는데, 이는 스캔된 총합 크기를 4 KB 단위로 센 뒤 절반으로 나눈 값입니다. us-east-1 온디맨드에서 $0.82입니다.

그 숫자 하나를 매시간 새로 고치면 월 $598입니다. 쓰기와 함께 카운터를 유지하거나 분석용 저장소로 내보내는 편이 더 저렴한 답이며, 둘 다 DynamoDB가 대신 해 주지 않는 일입니다.

잘 맞는 경우

그 반대 목록이 정확히 DynamoDB의 강점입니다. 어떤 규모에서도 한 자릿수 밀리초를 유지해야 하는, 예측 가능한 키 기반 읽기·쓰기의 대용량 운영 워크로드 — 장바구니, 세션, 프로필, 게임 상태, IoT 이벤트입니다. DynamoDB를 언제 써야 하는지 다루는 가이드가 그 긍정적인 쪽을 정리합니다.

더 알아보기

아직 고민 중이라면 다음으로 DynamoDB를 언제 써야 하는지를 읽어 보세요. 이미 DynamoDB를 쓰고 있는데 SQL이 그립다면, DynoTable이 데스크톱에서 라이브 테이블에 JOIN과 GROUP BY를 실행합니다. 그리고 요금 계산기는 확정하기 전에 여러분의 워크로드가 얼마일지 알려 줍니다.

참고 자료

위에 링크된 공식 AWS 문서를 기준으로 2026-07-13에 마지막으로 검증했습니다. 400 KB 수치는 2026-07-28에 다시 확인했으며, AWS가 이를 서비스 할당량 페이지에서 Constraints.html로 옮겼습니다.

2026-07-28에 Node v24.18.0의 @aws-sdk/client-dynamodb 3.1095.0을 통해 DynamoDB Local 3.3.0에 대해 재현했습니다. 두 ValidationException 메시지는 모두 그대로 옮긴 것입니다. Scan 비용은 동기화된 AWS 요금 표의 us-east-1 요율로 계산했습니다.