관계형 데이터베이스 대 NoSQL 데이터베이스: 시스템에 적합한 기반을 선택하는 방법

모든 데이터베이스는 데이터를 저장합니다. 하지만 그 유사점은 거기서 끝납니다. 관계형 데이터베이스와 NoSQL 데이터베이스는 데이터의 구조화, 저장, 쿼리 방식에 대해 근본적으로 상이한 철학을 반영하며, 이러한 차이는 이를 기반으로 구축된 시스템의 모든 계층에 걸쳐 파급됩니다.

이는 구식 대 신식, 혹은 단순 대 정교함의 문제가 아닙니다. 두 범주 모두 엄청난 규모로 사용되며, 오랜 시간 검증된 성숙한 시스템을 포함하고 있습니다. 핵심은 목적에 대한 적합성입니다. 즉, 어떤 모델이 귀하의 데이터 구조, 애플리케이션의 액세스 패턴, 그리고 사용자가 요구하는 일관성 보장에 더 잘 부합하는가 하는 문제입니다.

관계형 데이터베이스의 실제 정의

관계형 데이터베이스는 데이터를 테이블로 구성합니다. 테이블은 행과 열로 이루어지며, 이들 사이에는 명시적으로 정의된 관계가 존재합니다. 이름에 포함된 '관계형(relational)'이라는 용어는 테이블들이 서로 관련되어 있다는 사실(물론 실제로는 그렇지만)을 가리키는 것이 아니라, 동일한 속성을 공유하는 튜플의 집합이라는 수학적 개념인 '관계(relation)'를 의미합니다. 1970년 IBM의 에드거 코드(Edgar Codd)가 개발한 이 이론적 토대는 놀라울 정도로 오랜 시간 그 유효성을 입증해 왔습니다.

관계형 데이터베이스의 핵심 특징은 다음과 같습니다:

고정된 스키마. 데이터를 삽입하기 전에 구조를 정의합니다. 어떤 테이블이 존재하는지, 각 테이블에 어떤 열이 있는지, 각 열이 어떤 데이터형을 허용하는지, 그리고 어떤 제약 조건(NOT NULL, UNIQUE, CHECK 등)이 적용되는지 등을 정합니다. 스키마는 애플리케이션과 데이터베이스 간의 계약입니다.

정규화. 데이터는 중복을 제거하도록 구성됩니다. 고객의 이름은 고객 테이블에 한 번만 나타납니다. 모든 주문은 ID를 통해 해당 고객을 참조합니다. 이름이 변경되면 한 곳만 변경됩니다. 이는 단순히 정돈된 상태를 넘어 일관성을 보장하는 것입니다.

ACID 트랜잭션. 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 내구성(Durability). 트랜잭션은 완전히 완료되거나 아예 실행되지 않습니다. 한 계좌에서 다른 계좌로 돈을 이체할 때, 인출과 입금은 동시에 이루어지거나 둘 다 이루어지지 않습니다. 데이터베이스는 엔진 수준에서 이를 강제합니다.

SQL. 구조화된 쿼리 언어(Structured Query Language)는 관계형 데이터베이스를 위한 보편적인 인터페이스입니다. 이는 선언적 언어로서, 어떻게 얻을지가 아니라 무엇을 원하는지를 기술하며, 표현력이 매우 뛰어납니다. 조인, 집계, 윈도우 함수, 하위 쿼리, CTE: SQL의 모든 기능을 활용하면 별도의 애플리케이션 코드를 작성하지 않고도 데이터에 대해 복잡한 질문을 던질 수 있는 도구를 얻을 수 있습니다.

주요 관계형 데이터베이스인 PostgreSQL, MySQL, SQL Server, Oracle은 구체적인 기능 세트, 성능 특성, 라이선스 모델은 서로 다르지만 이러한 속성은 공유합니다. 특히 PostgreSQL은 엄격한 표준 준수와 탁월한 기능 세트를 결합하여 새로운 프로젝트의 기본 선택지가 되었습니다.

NoSQL 데이터베이스의 실제 정의

"NoSQL"은 여러 가지 서로 다른 데이터베이스 범주를 포괄하는 포괄적인 용어로, 주로 '무엇이 아닌지'를 통해 통합됩니다. 즉, 이들은 관계형이 아니며, SQL을 주 인터페이스로 사용하지 않습니다(일부는 SQL과 유사한 쿼리 언어를 지원하기도 합니다). 이 용어는 "SQL뿐만 아니라(not only SQL)"라는 의미로 이해하는 것이 더 정확하며, 이는 관계형 모델이 유일한 유효한 접근 방식이 아니라는 점을 인정하는 것입니다.

주요 NoSQL 범주는 다음과 같습니다:

문서 데이터베이스는 데이터를 문서(일반적으로 JSON 또는 BSON) 형태로 저장하며, 각 문서는 서로 다른 구조를 가질 수 있습니다. MongoDB가 가장 널리 사용되며, 그 외 CouchDB와 Firestore 등이 있습니다. 테이블이나 고정된 스키마가 없으며, 문서의 "컬렉션"에는 완전히 다른 필드를 가진 레코드가 포함될 수 있습니다.

키-값 저장소는 가장 단순한 모델로, 모든 레코드는 고유한 키로 참조 가능한 값입니다. Redis가 대표적인 예로, 캐싱, 세션 저장, 실시간 순위표 등에 광범위하게 사용됩니다. DynamoDB 또한 주로 키-값 저장소로 작동하며, 그 위에 문서 기능이 추가되어 있습니다.

컬럼 패밀리 스토어는 데이터를 행이 아닌 컬럼 단위로 구성하여, 수백만 행에 걸쳐 특정 컬럼을 매우 효율적으로 읽을 수 있게 합니다. Apache Cassandra와 HBase가 대표적인 예입니다. 이 모델은 쿼리 패턴이 사전에 알려진, 쓰기 작업이 많고 데이터량이 방대한 워크로드를 위해 설계되었습니다.

그래프 데이터베이스는 데이터를 노드와 에지, 즉 엔티티와 그들 간의 관계로 모델링합니다. Neo4j가 대표적인 예입니다. 엔티티 간의 관계가 쿼리의 주된 대상인 경우(소셜 네트워크, 추천 엔진, 사기 탐지 등), 그래프 데이터베이스는 깊이 재귀적인 SQL이 필요했을 쿼리를 자연스럽게 표현할 수 있습니다.

시계열 데이터베이스는 시간으로 인덱싱된 데이터에 최적화되어 있습니다: InfluxDB, TimescaleDB, Prometheus 등이 있습니다. 센서 측정값, 금융 시세, 애플리케이션 메트릭 등 타임스탬프가 항상 기본 키이며, 시간 범위를 대상으로 한 쿼리가 주된 액세스 패턴인 데이터가 여기에 해당합니다.

모든 것을 좌우하는 구조적 차이

관계형 데이터베이스와 NoSQL 데이터베이스 간의 가장 근본적인 차이는 구문이나 확장성이 아니라, 데이터 구조와 쿼리 유연성 간의 관계에 있습니다.

관계형 데이터베이스는 초기 스키마 규율을 대가로 최대의 쿼리 유연성을 제공합니다. 데이터가 정규화되고 유형이 지정되어 있으므로, 쿼리 시점에 거의 모든 질문을 던질 수 있습니다. 스키마를 설계할 때 예상하지 못했던 방식으로 테이블을 조인할 수 있습니다. 초기 설계 후 몇 달이 지나서 추가한 차원을 가로질러 집계할 수도 있습니다. 스키마는 데이터에 제약을 가하지만, 쿼리 언어는 자유를 제공합니다.

NoSQL 데이터베이스는 정반대의 절충점을 취합니다. 더 제한적인 쿼리 패턴을 대가로, 데이터를 구조화하고 기록하는 방식에 있어 유연성을 제공합니다. 문서 데이터베이스를 사용하면 마이그레이션 없이 어떤 형태의 데이터든 저장할 수 있습니다. 하지만 문서 간에 효율적으로 쿼리를 수행하려면 사전에 액세스 패턴을 파악하고, 이를 기반으로 데이터 구조를 설계해야 합니다.

이것이 바로 핵심적인 상충 관계입니다: 스키마 유연성 대 쿼리 유연성. 두 가지를 모두 가질 수는 있지만, 어느 정도까지만 가능합니다. 선택하는 데이터베이스 모델은 사용 사례에 있어 어떤 상충 관계가 더 수용 가능한지를 반영합니다.

CAP 정리와 그 중요성

분산 시스템은 일관성(Consistency), 가용성(Availability), 분할 내성(Partition Tolerance)을 동시에 보장할 수 없으며, 이 세 가지 중 최대 두 가지만 달성할 수 있습니다. 이것이 바로 CAP 정리이며, 이는 관계형 데이터베이스와 NoSQL 데이터베이스가 장애 상황에서 서로 다른 동작을 보이는 이유를 이해하는 이론적 토대입니다.

관계형 데이터베이스는 전통적으로 일관성과 분할 내성을 우선시합니다. 모든 읽기 작업은 가장 최근의 쓰기 내용을 반영합니다. 네트워크 분할이 발생하여 데이터베이스가 일관성을 보장할 수 없게 되면, 데이터베이스는 오래된 데이터를 제공하지 않기로 결정합니다. 즉, 데이터가 부정확해지는 대신 사용할 수 없게 되는 것입니다.

많은 NoSQL 데이터베이스, 특히 Cassandra나 DynamoDB처럼 수평 분산을 위해 설계된 데이터베이스는 가용성과 분할 내성을 우선시합니다. 이들은 네트워크 분할이 발생한 상황에서도 데이터를 제공하며, 일부 읽기 작업에서 오래된 값이 반환될 수 있음을 용인합니다. 이를 "최종 일관성(eventual consistency)"이라고 합니다. 모든 노드는 결국 동일한 값으로 수렴하지만, 그 사이에는 값이 일치하지 않을 수 있는 시간이 존재합니다.

실무적 함의: 애플리케이션이 은행 잔고, 재고 수량, 의료 기록 등 오래된 데이터를 읽는 것을 절대 허용할 수 없다면, 강력한 일관성(strong consistency)이 필요합니다. 반면, 소셜 미디어 피드, 제품 카탈로그, 사용자 프로필처럼 항상 가용성을 유지하기 위해 일시적인 비일관성을 감수할 수 있다면, 최종 일관성(eventual consistency)도 수용 가능하며 아키텍처 설계의 자유도를 높여줍니다.

실제 사례: 올바른 선택이 결과를 바꾼 경우

GitHub: 글로벌 플랫폼의 중심에 있는 PostgreSQL

GitHub는 PostgreSQL을 기반으로 세계 최대 규모의 소프트웨어 협업 플랫폼 중 하나를 운영하고 있습니다. 수백만 개의 리포지토리, 수십억 건의 이벤트, 사용자, 조직, 리포지토리, 풀 리퀘스트, 이슈, 댓글을 아우르는 복잡한 관계형 쿼리가 처리됩니다. 관계형 모델은 이 도메인에 적합합니다. 이러한 엔티티 간의 관계가 바로 제품이기 때문입니다. 풀 리퀘스트는 리포지토리에 속하며, 사용자가 작성하고, 다른 사용자가 검토하며, 이슈를 해결하고, CI 파이프라인을 트리거합니다.

수년 동안 GitHub는 읽기 전용 복제본을 갖춘 단일 주 PostgreSQL 인스턴스를 운영했습니다. 규모가 커짐에 따라 일부 워크로드를 위한 MySQL 샤딩 레이어인 Vitess와 연결 관리를 위한 ProxySQL을 도입했지만, 관계형 핵심 구조는 그대로 유지되었습니다. 여기서 얻을 수 있는 교훈은 PostgreSQL이 별다른 노력 없이 무한히 확장된다는 것이 아닙니다. 관계로 정의된 도메인에 관계형 모델이 적합했으며, 다른 데이터 모델로 마이그레이션하는 것이 더 많은 비용이 들었을 것이기 때문에 확장성에 투자한 노력이 그만한 가치가 있었다는 점입니다.

트위터: MySQL에서 혼합 아키텍처로의 고통스러운 마이그레이션

트위터는 MySQL로 시작했으며, 사용자 증가 속도가 단일 관계형 데이터베이스가 감당할 수 있는 한계를 넘어섬에 따라 잘 알려진 확장성 위기에 직면했습니다. 핵심 문제는 소셜 그래프, 즉 수억 명의 사용자 간 팔로워/팔로잉 관계와 타임라인 팬아웃 문제였습니다. 팔로워가 1,000만 명인 사용자가 트윗을 올리면, 그 트윗은 거의 즉시 1,000만 개의 타임라인에 표시되어야 했습니다.

트위터가 구현한 관계형 모델은 이러한 쓰기 팬아웃을 요구되는 속도로 처리할 수 없었습니다. 트위터는 소셜 그래프를 맞춤형 인메모리 스토어로 마이그레이션했고, 결국 타임라인에는 맨해튼(Manhattan, 내부 분산 키-값 스토어)을, 기타 쓰기 부하가 높은 워크로드에는 카산드라(Cassandra)를 채택했습니다.

여기서 얻을 수 있는 교훈은 미묘합니다. 트위터의 핵심 데이터인 트윗, 사용자, 관계는 근본적으로 관계형입니다. 문제는 데이터 모델이 아니라, 분산이 필요한 규모의 쓰기 볼륨과 팬아웃이었습니다. 이 마이그레이션은 비용이 많이 들고 기술적으로 복잡했으며, 수년간의 엔지니어링 투자가 필요했습니다. 트위터의 규모에서는 올바른 결정이었습니다. 하지만 다른 거의 모든 애플리케이션의 규모에서는 시기상조였을 것입니다.

MongoDB: 스키마 유연성에 대한 경고의 사례

2010년대 초, MongoDB의 인기가 급속히 높아지면서 많은 팀이 주로 스키마 유연성, 즉 스키마를 미리 정의하지 않고도 데이터 저장을 시작할 수 있는 기능을 이유로 이를 채택했습니다. 프로토타이핑 및 초기 개발 단계에서는 이것이 실제로 반복 작업을 가속화했습니다.

문제는 시스템이 성숙해지면서 드러났습니다. 스키마 강제 적용이 없자 데이터 불일치가 서서히 누적되었습니다. 필수로 지정되어야 할 필드가 누락되기도 했고, 정수여야 할 값이 문자열로 저장되기도 했습니다. 일관된 구조를 전제로 한 쿼리는 예상치 못한 결과를 반환했습니다. 팀들은 데이터베이스가 무료로 강제해 주었을 법한 검증 작업을 애플리케이션 수준에서 광범위하게 직접 작성해야 하는 상황에 처했습니다.

이는 데이터베이스로서 MongoDB의 실패가 아닙니다. MongoDB는 많은 사용 사례에 적합한 도구입니다. 이는 스키마 유연성이 무조건 좋다는 가정의 실패입니다. 유연성은 데이터 구조에 대해 고민해야 하는 비용을 미루었을 뿐, 그 비용을 없애지는 못했습니다. 규율 없이 MongoDB를 사용한 팀들은 관계형 데이터베이스가 제공했을 법한 보장 없이, 애플리케이션 코드 내에서 관계형 스키마의 약화된 버전을 구현하게 되었습니다.

Amazon DynamoDB: 적절한 사용 사례에서의 성공 사례

아마존의 장바구니는 NoSQL을 올바르게 적용한 대표적인 사례 중 하나입니다. 요구 사항은 명확했습니다. 장바구니는 항상 가용해야 했고(지역적 장애가 발생하더라도 고객이 항상 상품을 추가할 수 있어야 함), 방대한 쓰기 트래픽(수억 명의 사용자가 상품을 추가 및 삭제)을 처리해야 했으며, 액세스 패턴은 단순하고 사전에 알려져 있어야 했습니다(항상 고객 ID로 액세스).

DynamoDB의 탄생에 영감을 준 2007년 논문에서 아마존 엔지니어링 팀은 장바구니에 대해 의도적으로 '최종 일관성(eventual consistency)'을 선택했다고 설명했습니다. 즉, 네트워크 분할 중에 두 기기가 동시에 상품을 추가할 경우, 비록 잠시 동안 약간 일관성이 없는 상태가 나타날지라도 분할이 복구되면 두 추가 내역 모두 보존된다는 것입니다. 잠시 비일관성이 발생하더라도 항상 쓰기가 가능한 장바구니는, 가끔 사용할 수 없는 장바구니보다 더 가치가 있습니다.

이러한 사용 사례를 중심으로 한 DynamoDB의 설계 — 단순한 키-값 액세스, 알려진 쿼리 패턴, 일관성보다 가용성 우선 — 가 바로 이 서비스를 탁월하게 만드는 요소입니다. DynamoDB를 범용 관계형 데이터베이스로 사용하려 하여 여러 엔티티에 걸쳐 복잡한 쿼리를 실행하는 애플리케이션은 흔히 어려움을 겪습니다.

에어비앤비(Airbnb): 검색에는 엘라스틱서치(Elasticsearch), 데이터 정밀 관리에는 포스트그레SQL(PostgreSQL)

에어비앤비의 검색 기능 — 위치, 날짜, 가격, 편의 시설, 예약 가능 여부를 기준으로 숙소를 필터링하는 것 —은 어떤 관계형 데이터베이스도 대규모 환경에서 효율적으로 처리할 수 없는 쿼리입니다. 수백만 건의 숙소를 대상으로 지리적 검색, 전체 텍스트 일치, 복잡한 다중 속성 필터링을 결합한 작업은 바로 Elasticsearch가 설계된 용도입니다.

Airbnb는 Elasticsearch를 검색 레이어로 사용하면서 PostgreSQL을 기록 시스템으로 유지합니다. 숙소 정보가 업데이트되면, 변경 사항은 PostgreSQL(ACID 특성을 완전히 보장하는 '진실의 원천')에 기록된 후 비동기적으로 Elasticsearch(검색 경험의 특정 쿼리 패턴에 최적화된 검색 인덱스)로 전파됩니다.

이는 성숙한 아키텍처 패턴입니다. 각 영역에 적합한 데이터베이스를 사용하고, 명확한 '진실의 원천'을 유지하며, 여러 저장소를 동기화하는 데 따르는 운영상의 복잡성을 수용하는 방식입니다. 경계가 명확하고 장단점을 이해하고 있기 때문에 이 방식은 효과적입니다.

관계형 데이터베이스를 선택해야 할 때

관계형 데이터베이스는 대부분의 애플리케이션에 적합한 기본 선택지입니다. 다음은 관계형 데이터베이스가 명백히 올바른 선택인 경우입니다:

데이터 간에 의미 있는 관계가 존재할 때. 시스템 내의 엔티티들이 사용자-게시물, 주문-내역, 프로젝트-작업과 같이 중요한 방식으로 서로 연관되어 있다면, 관계형 모델은 이러한 관계를 직접적으로 표현하며 이를 효율적으로 쿼리할 수 있게 해줍니다.

강력한 일관성이 필요한 경우. 금융 거래, 재고 관리, 예약 시스템, 의료 기록 등 잘못된 읽기가 실제 결과를 초래할 수 있는 모든 영역에서는 ACID 보장이 필요합니다. 관계형 데이터베이스는 엔진 수준에서 이를 제공합니다.

쿼리 패턴이 완전히 예측되지 않는 경우. 설계 단계에서 완전히 예상할 수 없는 데이터 관련 질문에 애플리케이션이 답해야 한다면, SQL의 유연성은 매우 유용합니다. 잘 정규화된 스키마에 대해 즉석 쿼리를 작성할 수 있는 능력은 중요한 운영 자산입니다.

팀원이 SQL을 알고 있는 경우. 사소해 보일 수 있지만 그렇지 않습니다. SQL은 소프트웨어 엔지니어링 분야에서 가장 널리 이해되는 기술적 역량 중 하나입니다. 채용하는 모든 개발자가 어느 정도는 이를 알고 있을 것입니다. 인덱스 추가 방법, 쿼리 실행 계획 해석, 백업 관리와 같은 운영 지식은 널리 공유되어 있습니다. 관련 도구 생태계도 성숙해 있습니다.

무엇이 필요한지 확실하지 않다면. 확신이 서지 않을 때는 PostgreSQL부터 시작하세요. 데이터가 생각보다 더 구조화된 것으로 드러났을 때 문서 저장소에서 다시 관계형 모델로 마이그레이션하는 것보다, 실제 액세스 패턴을 파악한 후에 특화된 저장소를 도입하는 편이 더 쉽습니다.

NoSQL을 선택해야 할 때

관계형 모델로는 과도한 노력 없이는 특정 요구 사항을 충족할 수 없을 때 NoSQL이 올바른 선택입니다:

쓰기 양이 단일 노드가 처리할 수 있는 범위를 초과할 때. 애플리케이션이 지리적으로 분산된 시스템 전반에서 초당 수십만 건의 쓰기를 지속해야 한다면, 다수의 노드에 걸친 수평적 확장이 필요합니다. Cassandra와 같은 컬럼 패밀리 스토어는 이를 위해 설계되었습니다. 관계형 데이터베이스도 분산될 수 있지만, 이는 본래의 운영 방식은 아닙니다.

데이터가 진정한 의미에서 스키마가 없거나 매우 가변적인 경우. 서로 다른 제품 유형이 완전히 다른 속성을 가지는 제품 카탈로그, 콘텐츠 유형이 빠르게 진화하는 CMS, 이벤트 스키마가 외부 시스템에 의해 정의되는 로깅 시스템 등 — 이러한 경우에는 데이터베이스에 의해 구조가 강제되지 않는 문서 저장소가 유용합니다.

주요 액세스 패턴이 대규모 키-값 조회인 경우. 세션 스토어, 캐시, 실시간 리더보드, 기능 플래그 등 — 항상 단일 키로 데이터에 액세스하고 조인이나 집계 작업이 전혀 필요 없는 워크로드는 키-값 스토어의 단순성과 성능의 이점을 누릴 수 있습니다.

그래프를 모델링하고 있다면. 주요 쿼리가 관계 탐색과 관련된 경우 — 친구의 친구 모두 찾기, 두 노드 간 최단 경로 파악, 순환 의존성 탐지 등 — 그래프 데이터베이스는 재귀적 SQL보다 이러한 쿼리를 더 자연스럽게 표현하고 더 효율적으로 실행합니다.

시계열 최적화가 필요합니다. 초당 수백만 건의 센서 측정값, 금융 티크, 애플리케이션 메트릭이 발생하고 쿼리가 주로 시간 범위를 대상으로 하는 경우, 타임스탬프 열이 있는 관계형 저장소보다 전용 시계열 데이터베이스를 사용하는 것이 더 적합합니다.

다중 데이터베이스의 현실

관계형 데이터베이스와 NoSQL의 대립 구도에 대해 이해해야 할 가장 중요한 점은, 대부분의 성숙한 시스템에서 이것이 '둘 중 하나'를 선택해야 하는 문제가 아니라는 것입니다. 대규모 시스템은 일반적으로 각기 담당하는 특정 워크로드에 맞춰 선택된 여러 데이터베이스를 일상적으로 사용합니다.

기록용 시스템(System of Record)에는 PostgreSQL을, 세션 캐싱 및 속도 제한에는 Redis를, 전체 텍스트 검색에는 Elasticsearch를, 애플리케이션 메트릭스에는 InfluxDB를 사용합니다. 이 스택의 각 데이터베이스는 자신이 가장 잘하는 일을 수행하며, 애플리케이션 계층이 이들 간의 일관성을 관리합니다.

이러한 복잡성이 초래하는 운영 비용은 실재합니다. 데이터베이스가 하나 추가될 때마다 모니터링하고, 백업하고, 확장하고, 이해해야 할 시스템이 하나 더 생기는 셈입니다. 여러 저장소를 일관되게 유지하기 위해 필요한 엔지니어링 기술 — 예를 들어 PostgreSQL에 대한 쓰기 작업은 성공했으나 이후 Elasticsearch 업데이트가 실패하는 오류 시나리오를 처리하는 것 — 은 결코 사소한 문제가 아닙니다.

거의 모든 애플리케이션의 출발점은 단일 관계형 데이터베이스여야 합니다. 특정하고 명확히 이해된 요구 사항을 충족하기 위해 전문 저장소가 반드시 필요한 경우에만 이를 추가하십시오. 시기상조인 데이터베이스 다각화는 일종의 시기상조 최적화입니다. 즉, 그 복잡성이 필요한지 여부를 파악하기도 전에 복잡성을 더하는 것입니다.

결정 내리기

데이터베이스를 선택할 때 실제로 중요한 질문들:

일관성 요구사항은 무엇입니까? "사용자가 오래된 데이터를 읽으면 어떻게 되나요?"라는 질문에 대한 답이 "그건 심각한 문제입니다"라면 ACID가 필요합니다. 만약 "그건 약간 성가시지만 감수할 수 있습니다"라면 선택의 여지가 있습니다.

쿼리 패턴은 어떤가요? 데이터에 어떻게 접근할지 정확히 알고 있고, 그 접근 패턴이 단순하며 처리량이 많다면, 이에 맞춰 최적화할 수 있습니다. 접근 패턴이 복잡하거나 완전히 파악되지 않았다면, SQL의 유연성이 큰 장점이 됩니다.

쓰기 처리량은 어느 정도인가요? 대다수의 애플리케이션에서, 적절한 하드웨어에 잘 튜닝된 PostgreSQL 인스턴스는 초당 수천 건의 쓰기 작업을 문제없이 처리합니다. 이것이 진정으로 부족한 경우는 2010년대의 NoSQL 열풍이 시사했던 것보다 훨씬 드뭅니다.

데이터의 형태는 어떤가요? 매우 균일하고 밀접하게 연관된 데이터는 관계형 모델에 잘 맞습니다. 반면, 매우 다양하고 느슨하게 연관된 데이터는 문서형 모델에 더 적합할 수 있습니다.

팀의 전문 지식은 어떤가요? 운영상의 친숙도는 중요합니다. PostgreSQL을 깊이 이해하는 팀은, 비록 NoSQL 데이터베이스가 이론적으로는 더 적합할지라도, 배우고 있는 NoSQL 데이터베이스보다 PostgreSQL을 기반으로 더 신뢰할 수 있는 시스템을 구축할 것입니다.

관계형 데이터베이스가 50년 동안의 기술적 변화를 견뎌낸 이유는 그것이 항상 최고의 도구이기 때문이 아니라, 유연하고 신뢰할 수 있으며 잘 이해되고 수십 년간의 운영 노하우가 뒷받침되는 탁월한 기본 옵션이기 때문입니다. 무엇을 얻고 무엇을 포기하는지 명확히 이해한 상태에서 신중하게 관계형 데이터베이스에서 벗어나십시오.