새 시스템을 준비할 때 “Oracle과 MySQL 중 무엇을 쓸까?”부터 묻기 쉽습니다. 그런데 제품 이름을 먼저 정하면 정작 중요한 조건을 놓치곤 해요. 주문과 결제처럼 여러 변경을 한 묶음으로 처리해야 하는지, 검색이 중심인지, 서버 없이 앱 안에 저장하면 되는지에 따라 후보가 완전히 달라집니다.
그래서 데이터베이스는 단순한 속도 순위보다 역할로 나눠 보는 편이 정확합니다. 아래 비교는 특정 버전의 벤치마크가 아니라, 9개 제품이 어떤 문제에 잘 맞고 도입 전에 무엇을 확인해야 하는지 정리한 선택 안내표입니다.
핵심 답변
모든 환경에서 가장 좋은 데이터베이스는 없습니다. 데이터 구조, 트랜잭션, 검색 방식, 장애 복구 기준, 운영 인력과 비용을 먼저 적고 그 조건에 맞는 제품을 좁혀야 해요. 한 서비스가 관계형 데이터베이스와 Redis, Elasticsearch를 역할별로 함께 쓰는 것도 자연스러운 선택입니다.
관계형 데이터베이스 6종은 무엇이 다른가
관계형 데이터베이스는 데이터를 테이블의 행과 열로 관리하고, 서로 연결된 변경을 일관되게 처리하는 데 익숙한 도구입니다. 진료와 처방, 주문과 결제, 재고와 출고처럼 관계가 분명한 업무라면 먼저 이 범주에서 후보를 찾게 됩니다. 다만 같은 관계형 제품이라도 비용과 배포 방식, 관리 도구, 확장 기능은 꽤 다릅니다.
| 제품 | 잘 맞는 상황 | 강점 | 도입 전 확인 |
|---|---|---|---|
| Oracle Database | 병원·금융·공공·대기업의 핵심 업무 | 트랜잭션과 데이터 일관성, 기업용 관리·가용성 기능이 풍부합니다. | 에디션별 기능, 라이선스와 인프라 비용, 전문 운영 인력을 함께 봐야 합니다. |
| MySQL | 쇼핑몰과 일반 웹 서비스 | 개발 생태계가 크고 관련 자료와 도구를 찾기 쉽습니다. | 필요한 고가용성 구성과 기능이 선택한 버전·배포판에서 지원되는지 확인해야 합니다. |
| Microsoft SQL Server | Microsoft와 .NET 중심의 기업 시스템 | 관리 도구가 잘 갖춰져 있고 Microsoft 제품과 연결하기 편합니다. | 에디션별 기능과 라이선스, 기존 인프라와의 조합을 따져야 합니다. |
| PostgreSQL | 복잡한 업무 시스템과 신규 데이터 서비스 | 데이터 무결성을 중시하며 다양한 데이터 형식과 확장 기능을 제공합니다. | 설계와 튜닝뿐 아니라 백업·복구 체계를 운영할 역량이 필요합니다. |
| MariaDB | 웹 서비스와 MySQL 계열 대체 환경 | MySQL 계열 사용자에게 구조와 사용 방식이 비교적 친숙합니다. | MySQL과 발전 방향이 달라졌으므로 기능·드라이버 호환성을 실제 환경에서 확인해야 합니다. |
| SQLite | 모바일 앱·데스크톱 프로그램·로컬 저장 | 별도 서버 없이 애플리케이션이 데이터베이스 파일을 직접 사용합니다. | 여러 서버의 동시 쓰기가 몰리는 중앙 업무 시스템과는 성격이 다릅니다. |
Oracle이나 SQL Server는 제품 기능뿐 아니라 지원 체계와 운영 조직까지 포함해 검토하는 경우가 많습니다. MySQL과 MariaDB는 웹 개발자에게 익숙하지만 서로 완전히 같은 제품은 아니에요. PostgreSQL은 복잡한 데이터 모델과 확장 기능이 필요할 때 매력적인 후보이고, SQLite는 중앙 서버보다 앱 내부 저장소에 가깝습니다.
MongoDB·Redis·Elasticsearch는 같은 후보가 아니다
이 세 제품을 한데 묶어 “NoSQL 중 무엇이 빠른가”라고 물으면 답이 흐려집니다. MongoDB는 문서 모델, Redis는 메모리 기반 자료 구조 처리, Elasticsearch는 검색과 분석을 중심으로 설계됐습니다. 서로 대체재라기보다 맡는 일이 다른 도구에 가까워요.
| 제품 | 주 역할 | 어울리는 예 | 주의할 점 |
|---|---|---|---|
| MongoDB | 문서 단위 저장과 조회 | 상품 카탈로그·콘텐츠·구조가 다양한 문서 데이터 | 스키마가 유연해도 설계가 사라지는 것은 아닙니다. 함께 읽고 쓰는 데이터와 조회 패턴을 먼저 정해야 합니다. |
| Redis | 빠른 자료 구조 처리 | 캐시·세션·실시간 순위·대기열 | 메모리 비용과 장애 시 허용할 데이터 손실 범위를 정하고 영속성 정책을 선택해야 합니다. |
| Elasticsearch | 분산 검색과 분석 | 문서·상품 검색, 로그 분석과 모니터링 | 색인·샤드·보존 정책을 운영해야 하며 거래 원장의 단순 대체재로 보면 곤란합니다. |
예를 들어 주문 원장은 관계형 데이터베이스에 두고, 자주 읽는 상품 정보는 Redis에 캐시하며, 상품 검색은 Elasticsearch가 맡을 수 있습니다. 제품 수를 늘리는 것이 늘 정답은 아니지만, 역할을 나누면 각 저장소의 장점을 더 분명하게 활용할 수 있습니다. 대신 백업, 모니터링, 장애 대응 대상도 함께 늘어난다는 점은 비용에 넣어야 합니다.
제품 이름보다 먼저 적어야 할 여섯 가지
선택 회의에서 제품 이름만 오가기 시작했다면 잠시 멈추고 아래 질문부터 답해 보는 편이 좋습니다.
- 데이터 구조: 행과 열의 관계가 분명한가, 문서 단위로 함께 읽는가, 검색 색인이 필요한가?
- 트랜잭션: 결제와 재고처럼 여러 변경이 반드시 함께 성공하거나 실패해야 하는가?
- 부하: 읽기와 쓰기 중 어디에 부하가 몰리며, 동시 접속과 데이터 증가 속도는 어느 정도인가?
- 복구 기준: 허용 가능한 중단 시간과 데이터 손실 범위는 얼마인가?
- 운영 역량: 백업, 복제, 업그레이드와 장애 대응을 맡을 사람이 있는가?
- 전체 비용: 라이선스뿐 아니라 서버, 스토리지, 네트워크, 모니터링과 교육 비용까지 감당할 수 있는가?
작은 서비스라고 해서 정합성이 덜 중요한 것은 아닙니다. 반대로 데이터가 많아도 거래 처리보다 검색 응답이 더 중요한 서비스가 있어요. 제품의 장단점은 이런 조건과 나란히 놓았을 때 비로소 선택 기준이 됩니다.
병원 Oracle RAC 운영에서 확인한 것
제가 근무하는 병원도 Oracle Database를 사용합니다. 예전에는 Oracle을 쓰고 있었지만 응답이 느렸고 CPU 사용률도 높았습니다. 이름난 데이터베이스를 도입했다는 사실만으로 시스템 전체가 빨라지는 것은 아니었습니다.
이후 올플래시 스토리지를 도입하고 OS 영역을 포함한 디스크 구성을 손봤습니다. 서버당 64코어와 512GB 메모리를 갖춘 두 대의 서버로 Oracle RAC를 운영한 뒤에는 체감 성능이 좋아졌어요. 상위 Xeon Gold나 Platinum이 아닌 Xeon Silver급 CPU였지만, 업무가 몰리는 시간에도 서버당 전체 CPU 사용률은 대체로 10%를 넘지 않았습니다.
경험 수치를 읽을 때 주의할 점
여러 구성을 함께 바꿨기 때문에 성능 향상을 CPU나 스토리지 하나의 효과로 단정할 수는 없습니다. SQL과 인덱스, 메모리, 스토리지 지연, 네트워크와 RAC 구성도 결과에 영향을 줍니다. 이 수치는 제품 간 벤치마크가 아니라 실제 시스템은 전체 구성이 균형을 이뤄야 한다는 사례로 봐야 합니다.
그래서 무엇을 고르면 될까
업무 데이터의 관계와 트랜잭션이 중심이라면 먼저 관계형 데이터베이스를 비교하세요. 앱 안의 가벼운 로컬 저장에는 SQLite가 자연스럽고, 문서 구조가 조회 방식과 잘 맞으면 MongoDB를 검토할 수 있습니다. 짧은 응답 시간이 필요한 캐시와 세션에는 Redis, 전문 검색과 로그 분석에는 Elasticsearch가 제 역할을 합니다.
후보를 두세 개로 줄였다면 같은 데이터와 대표 쿼리로 작은 검증 환경을 만드는 것이 좋습니다. 기능표만 보지 말고 장애 복구, 버전 업그레이드, 백업 시간, 드라이버 호환성과 운영 난이도까지 직접 확인해야 해요. 가장 유명한 제품이 아니라 우리 데이터와 팀이 오래 운영할 수 있는 제품이 현실적인 답입니다.