공통 판단 기준

업종이 달라도 먼저 정하는 것은 “어떤 상태를 가장 안전하게 기록해야 하는가”입니다.

기본 DB는 핵심 상태를 지키고, Redis·검색·피드·시계열 저장소는 성능 병목이 생기는 부분만 분리해 붙입니다.

01

정확한 기록이 먼저

거래, 계좌, 결제처럼 틀리면 안 되는 상태를 RDB가 중심에서 관리합니다.

금융/은행 Oracle / PostgreSQL

거래·계좌 정확성이 우선이라 강한 일관성과 트랜잭션이 핵심입니다.

Redis는 세션·캐시만 맡겨 거래 DB 부담을 줄입니다.

게임 MySQL

계정·결제는 정확히 기록하고, 실시간 상태는 별도로 빠르게 처리합니다.

Redis는 랭킹·세션·실시간 상태, MongoDB는 게임 로그를 맡습니다.

02

웹 서비스 기본형

주문·회원 같은 핵심 모델은 RDB에 두고, 검색이나 유연한 문서는 필요할 때만 분리합니다.

이커머스 MySQL / PostgreSQL

주문·결제는 RDB에 두고, 상품 정보와 검색 요구가 커지면 전용 저장소를 붙입니다.

MongoDB는 카탈로그, Redis는 캐시, Elasticsearch는 검색을 담당합니다.

스타트업 MVP PostgreSQL

운영 복잡도를 늘리지 않고 핵심 모델을 한곳에서 빠르게 굴리는 선택입니다.

Redis만 더해 캐시·세션을 처리하고 구조는 단순하게 유지합니다.

03

읽기·시간 흐름을 분리

대량 조회, 피드, 연속 센서값처럼 접근 패턴이 다르면 전용 저장소가 더 효율적입니다.

SNS/미디어 MySQL

사용자 관계는 RDB에 두고, 피드처럼 읽기·쓰기 부하가 큰 부분은 따로 분리합니다.

Cassandra는 타임라인, Redis는 캐시, Elasticsearch는 검색을 맡습니다.

IoT/센서 InfluxDB / TimescaleDB

센서값은 시간순 적재와 구간 조회가 핵심이라 시계열 DB가 중심이 됩니다.

Redis는 실시간 대시보드 응답을 빠르게 유지합니다.