DB를 고를 때는 제품 이름보다 “무엇을 지키는가”를 먼저 봅니다.
상태를 정확히 보존해야 하는지, 질의를 빠르게 넓혀야 하는지, 전역 확장을 감당해야 하는지에 따라 계층이 갈립니다.
선택 전에 던지는 질문
상태 보존
주문, 결제, 재고처럼 중간 상태가 틀리면 안 되는가?
질의 형태
조인과 제약 조건이 중요한가, 문서·그래프·키 조회가 중심인가?
확장 위치
단일 서버를 키울 문제인가, 여러 지역과 노드로 나눌 문제인가?
운영 부담
일관성, 백업, 장애 대응을 DB가 맡을지 서비스가 맡을지 정해야 한다.
역할별 저장 엔진
RDBMS
정합성과 SQL을 기본값으로 둔다
트랜잭션, 조인, 제약 조건이 중요한 업무의 기준선입니다.
NoSQL
데이터 모양과 접근 패턴에 맞춘다
Key-Value, Document, Graph, Column 계열이 서로 다른 조회 방식을 담당합니다.
NewSQL
SQL 모델을 유지한 채 분산을 붙인다
관계형 개발 경험을 유지하면서 복제, 샤딩, 글로벌 일관성을 더합니다.
전용 엔진
검색·시계열·벡터처럼 특수 질의를 맡긴다
범용 DB를 억지로 늘리기보다 특정 질의 엔진을 곁에 둡니다.
정리: 관계형 코어는 상태의 기준점을 잡고, 확장과 특수 질의는 별도 저장소나 서비스로 분리하면서 전체 시스템을 설계합니다.