데이터베이스 종류와 서비스별 선택 기준
데이터베이스 종류가 많아 우리 서비스에 무엇이 맞는지 고민되시나요? 관계형·문서형·키값형과 벡터·그래프·시계열의 특징, 조회 방식과 라이선스를 함께 살피는 선택 기준을 정리합니다.
안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.
오늘의 인사이트 요약
데이터베이스 종류는 관계형·문서형·키값형 같은 모델과 벡터·그래프·시계열 같은 기능을 기준으로 구분하며 서로 겹치기도 합니다.
주문과 결제를 다루는 서비스는 관계형을 먼저 검토하고, 캐시나 벡터 검색이 필요할 때 종류를 더합니다.
MongoDB와 Redis는 라이선스를 바꾼 이력이 있어 데이터베이스 종류 비교 때 라이선스도 봐야 합니다.
데이터베이스 종류는 데이터 모델과 조회 방식에 따라 나눌 수 있습니다. 관계형·문서형·키값형처럼 저장 구조로 나누기도 하고, 벡터 검색이나 시계열 처리처럼 용도를 기준으로 구분하기도 합니다. 오늘은 데이터베이스 종류와 서비스별 선택 기준을 비교해보겠습니다.
데이터베이스 종류는 관계형과 비관계형으로 먼저 나뉩니다
관계형 데이터베이스는 표와 SQL로 데이터를 다룹니다.
회원과 주문처럼 행과 열로 정리되는 데이터를 표에 나눠 담고 키로 잇습니다. 설계는 번거롭지만 돈이 오가는 기록처럼 정합성이 중요한 데이터에 강합니다.
비관계형 데이터베이스는 데이터 모양에 맞는 방식으로 저장합니다.
NoSQL로 묶어 부르지만 문서형·키값형 등 저장 방식이 다양합니다. 한 제품이 여러 모델을 지원하기도 하므로 분류 지도는 주요 용도를 단순화한 설명입니다.
관계형 데이터베이스 종류, MySQL과 PostgreSQL은 어떻게 다를까요
MySQL은 오라클이 GPLv2와 상용 라이선스로 함께 제공합니다.
MySQL 공식 사이트 기준으로 서버는 GPLv2로 쓸 수 있고, 배포·결합 방식에 따라 GPL 의무나 상용 계약의 적용 여부가 달라집니다. 실제 제품에 포함할 때는 배포 조건을 검토합니다.
PostgreSQL은 BSD·MIT와 비슷한 자유로운 라이선스를 씁니다.
상용 서비스에도 조건이 가볍습니다. 확장 기능을 붙이면 JSON 데이터와 벡터 검색(pgvector)까지 한 DB에서 해결됩니다.
비관계형 데이터베이스 종류, 문서형과 키값형은 라이선스부터 봅니다
MongoDB는 JSON 같은 문서를 그대로 저장합니다.
필드가 자주 바뀌는 콘텐츠와 잘 맞습니다. 공식 라이선스 페이지에 따르면 2018년 10월 16일 이후 나온 Community Server는 SSPL을 따르는데, SSPL은 OSI 승인 오픈소스가 아니어서 법무 검토가 필요할 수 있습니다.
Redis는 메모리에 키와 값을 두는 대표적인 키값형 DB입니다.
세션, 순위, 캐시처럼 빠른 읽기에 씁니다. 공식 페이지를 보면 7.2까지 BSD-3였다가 2024년 3월 RSALv2·SSPLv1로 바뀌었고 Redis 8부터는 AGPLv3도 고를 수 있게 됐습니다. 2024년에는 리눅스 재단에서 BSD 라이선스의 Valkey 프로젝트가 출범했습니다. PostgreSQL과 문서형 BaaS 비교는 수파베이스 vs 파이어베이스 글에서 다뤘습니다.
벡터 데이터베이스 종류와 그래프·시계열 DB는 언제 필요할까요
벡터 데이터베이스는 의미가 가까운 데이터를 찾아줍니다.
문장과 이미지를 숫자 벡터로 저장해 비슷한 것을 찾고, RAG 챗봇의 검색 단계를 맡습니다. 벡터 데이터베이스 종류는 관리형인 Pinecone, Apache 2.0 오픈소스인 Milvus와 Qdrant, PostgreSQL 확장인 pgvector로 나눠 볼 수 있습니다. 규모가 작다면 PostgreSQL에 pgvector를 얹어도 됩니다.
그래프 DB는 관계 자체를 데이터로 다룹니다.
친구 추천이나 이상 거래 탐지처럼 연결을 여러 단계 따라갈 때 맞습니다. Neo4j의 Community Edition은 GPLv3입니다.
시계열 DB는 시간 순서로 쌓이는 값을 다룹니다.
센서 값이나 서버 지표처럼 초 단위로 쌓이는 데이터를 기간별로 묶어 봅니다. InfluxDB는 제품과 버전마다 기능·라이선스가 다르므로 도입할 배포판의 조건을 확인합니다.
데이터베이스 종류 비교, 서비스 유형별로 이렇게 고릅니다
서비스 유형 | 먼저 검토할 DB | 이유 |
|---|---|---|
커머스·예약·정산 | PostgreSQL, MySQL | 주문·결제 정합성 |
콘텐츠·커뮤니티 | MongoDB, PostgreSQL(JSON) | 필드가 자주 바뀜 |
세션·랭킹·캐시 | Redis, Valkey | 빠른 읽기 |
AI 검색·챗봇 | pgvector, Qdrant, Milvus, Pinecone | 의미 검색 |
IoT·모니터링 | InfluxDB | 시간 단위 집계 |
라이선스도 다시 봐야 합니다. DB를 내부에서만 쓰는지, 고객에게 DB 자체를 제공하는지에 따라 영향이 달라집니다.
개발사와 첫 미팅에서는 우리 서비스에서 절대 틀리면 안 되는 데이터는 무엇인가요?라고 물어보시면 됩니다. 그 답이 주문과 결제라면 관계형을 중심에 두고 나머지 종류는 필요할 때 붙입니다.
설정과 적용 조건을 더 살펴보려면 Redis 버전별 라이선스 · MongoDB SSPL 안내를 참고해 보세요.
데이터 구조를 서비스 기능과 연결합니다
똑똑한개발자는 백엔드·인프라와 관리자 시스템을 함께 개발합니다. 데이터베이스를 고를 때도 제품 이름에 앞서 어떤 데이터를 저장하고 어떤 화면에서 조회하는지 연결해 볼 필요가 있습니다. 필요한 기능과 운영 환경을 함께 살펴 저장 구조를 구체화합니다.
서비스의 데이터 구조를 어디부터 정할지 고민되시나요? 아래 링크로 문의해 주시면 핵심 데이터와 조회·수정 흐름을 함께 살펴보겠습니다.
감사합니다. :)
데이터 구조와 조회 방식에 맞는 DB 선택 기준을 정리합니다.
https://www.toktokhan.dev/contact?utm_source=landing&utm_campaign=database-types&utm_medium=database-types&utm_term=%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%A2%85%EB%A5%98