MongoDB vs PostgreSQL: 2026년, 올바른 데이터베이스 선택

이 비교를 바라보는 방법

관계, 제약 조건, 트랜잭션, 유연한 보고가 워크로드의 중심이라면 PostgreSQL을 선택하세요. 대부분의 작업이 필드 구성이 크게 달라질 수 있는, 크기가 제한된 독립 문서를 읽거나 업데이트하는 일이라면 MongoDB를 선택하세요. 어느 엔진도 언제나 더 빠르거나 더 단순한 것은 아닙니다.

기능 목록보다 애플리케이션에서 출발하세요. 두 시스템이 API로 JSON을 제공하더라도, 청구 시스템의 실패 조건은 콘텐츠 카탈로그와 다릅니다. 데이터베이스는 애플리케이션의 가장 어려운 작업을 단지 가능하게 하는 데 그치지 않고, 일상적으로 처리할 수 있게 해야 합니다.

두 선택지를 다음 다섯 가지 구체적인 질문으로 평가하세요.

• 어떤 레코드가 하나의 트랜잭션에서 함께 바뀌어야 하나요?
• 어떤 쿼리가 엔터티 경계를 넘으며, 얼마나 자주 바뀌나요?
• 애플리케이션 코드가 실패해도 반드시 유지되어야 하는 규칙은 무엇인가요?
• 하나의 논리적 레코드는 얼마나 커질 수 있으며, 그 자식 컬렉션은 제한 없이 커질 수 있나요?
• 누가 데이터베이스를 운영하고, 복원하고, 튜닝하고, 장애에 대응하나요?

SaaS 계정, 권한, 주문, 청구, 재고, 감사 추적, CRM, ERP에는 보통 PostgreSQL이 위험이 더 낮은 기본 선택입니다. 이런 영역에는 다대다 관계와 테이블, 외래 키, 고유 제약 조건, SQL에 잘 맞는 불변 조건이 많습니다.

MongoDB는 콘텐츠 항목, 테넌트별 속성이 있는 제품 레코드, 구성 문서, 이벤트 페이로드처럼 보통 하나의 객체로 가져오는 집합에 잘 맞습니다. 문서 구조의 유연성은 첫 구현을 빠르게 만들 수 있지만, 팀이 스키마 변경을 계속 관리해야 합니다.

각 데이터베이스가 명확히 분리된 영역을 맡는다면 둘을 함께 쓰는 것도 타당합니다. 경계가 모호하면 비용이 큽니다. 저장소가 둘이면 백업 시스템, 모니터링 방식, 보안 구성, 동기화 메커니즘도 둘이 됩니다. 한 데이터베이스가 지속적인 모델링 또는 확장 문제를 일으킬 때만 그 비용을 감수하세요.

데이터 모델: 문서인가 관계형 테이블인가

MongoDB는 크기가 제한된 집합으로 저장할 수 있는 데이터에 잘 맞고, PostgreSQL은 독립적으로 바뀌는 엔터티 사이의 관계가 데이터 가치를 결정할 때 잘 맞습니다. 이 차이는 JSON과 행의 차이보다 깊습니다. 일관성 규칙이 어디에 자리 잡는지를 결정하기 때문입니다.

MongoDB 주문은 배송 주소와 주문 항목을 내장할 수 있습니다.

{
  "_id": "order_1042",
  "customerId": "customer_28",
  "status": "paid",
  "shippingAddress": {
    "city": "Austin",
    "country": "US"
  },
  "items": [
    { "productId": "product_7", "quantity": 2, "unitPrice": 19.95 }
  ]
}

인덱스를 사용하는 한 번의 조회로 완전한 주문을 반환할 수 있습니다. 단일 업데이트로 주문과 내장 항목도 원자적으로 바꿀 수 있습니다. 이 부분들이 같은 생명주기를 공유하고 배열 크기가 제한되어 있다면 매력적입니다.

이에 대응하는 PostgreSQL 모델은 독립적으로 의미 있는 사실을 분리합니다.

CREATE TABLE orders (
    id bigint PRIMARY KEY,
    customer_id bigint NOT NULL REFERENCES customers(id),
    status text NOT NULL,
    placed_at timestamptz NOT NULL
);

CREATE TABLE order_items (
    order_id bigint NOT NULL REFERENCES orders(id),
    product_id bigint NOT NULL REFERENCES products(id),
    quantity integer NOT NULL CHECK (quantity > 0),
    unit_price numeric(12, 2) NOT NULL CHECK (unit_price >= 0),
    PRIMARY KEY (order_id, product_id)
);

이 모델은 주문 간 보고와 제품 관계를 직접적으로 다룰 수 있게 합니다. 데이터베이스는 존재하지 않는 주문이나 제품을 가리키는 항목을 거부할 수 있습니다. 구매 시 기록한 가격을 보존하면서 제품은 독립적으로 변경할 수도 있습니다.

계정이 생성한 모든 이벤트처럼 제한 없이 늘어나는 컬렉션에는 내장이 맞지 않습니다. 계속 커지는 문서는 쓰기 병목이 되고, 더 많은 대역폭을 쓰며, 결국 MongoDB의 16 MiB 문서 제한에 도달합니다. 그런 이벤트는 별도 문서로 저장하세요.

정규화를 지나치게 해도 문제입니다. 작은 값 객체를 여러 테이블로 나누면 유용한 독립성 없이 조인만 늘어납니다. 완료된 주문에 기록한 배송 주소는 대개 고객의 현재 주소를 실시간으로 참조하는 값이 아니라 과거 시점의 스냅샷입니다.

오래가는 모델링 원칙은 함께 바뀌고 크기가 제한된 데이터는 내장하는 것입니다. 독립적으로 바뀌거나, 많은 관계에 참여하거나, 예측 가능한 상한 없이 커지는 데이터는 참조하거나 정규화하세요.

스키마 변경과 데이터 무결성

MongoDB는 필드를 추가하기 쉽고 PostgreSQL은 일관된 형태를 강제하기 쉽습니다. 어느 시스템에서든 운영 환경의 안전성은 규율 있는 마이그레이션에 달려 있습니다.

MongoDB 컬렉션에는 서로 다른 필드와 타입을 가진 문서가 있을 수 있습니다. 이 유연성은 테넌트나 콘텐츠 유형별 속성이 다를 때 도움이 되지만, 같은 개념의 호환되지 않는 여러 버전을 만들 수도 있습니다. 이름을 바꾼 필드 때문에 이전 문서가 남을 수 있고, 모든 읽기 코드에 대체 처리 로직이 필요해집니다.

MongoDB는 JSON Schema 스타일 규칙으로 컬렉션 검증을 지원합니다. 팀은 검증을 점진적으로 도입하고, 기존 문서를 백필한 다음, 정한 형태를 위반하는 새 쓰기를 거부할 수 있습니다. 스키마 버전 필드는 작업자가 이전 문서를 예측 가능하게 마이그레이션하는 데 도움이 되지만 검증을 대체하지는 않습니다.

PostgreSQL의 변경은 명시적입니다. 보통 먼저 NULL을 허용하는 열을 추가하고, 필요하다면 이전 형식과 새 형식을 모두 쓰는 코드를 배포한 뒤, 통제된 배치로 백필하고, 데이터를 검증한 다음, 더 엄격한 제약 조건을 추가합니다. 대규모 인덱스는 쓰기 중단을 줄이기 위해 동시에 만들 수 있습니다. 외래 키와 일부 제약 조건도 전체 검증 전에 단계적으로 도입할 수 있습니다.

엔진이 표현할 수 있는 유용한 불변 조건은 데이터베이스에 두세요.

• 식별자, 멱등성 토큰, 소유자당 하나만 허용하는 레코드에는 고유 제약 조건을 사용하세요.
• 누락된 데이터를 절대로 가리키면 안 되는 관계에는 외래 키를 사용하세요.
• 수량이 양수여야 한다는 지역 규칙에는 CHECK 제약 조건을 사용하세요.
• 원격 서비스나 자주 바뀌는 정책이 필요한 상황별 규칙에는 애플리케이션 검증을 사용하세요.
• 지원하는 모든 스키마 버전에서 마이그레이션 경로가 작동하는지 테스트로 검증하세요.

유용한 오류 메시지와 비즈니스 워크플로를 위해 애플리케이션 검증은 계속 필요합니다. 데이터베이스 제약 조건은 경쟁 상태, 빠진 코드 경로, 관리 스크립트, 같은 데이터를 쓰는 미래 서비스에 맞서는 최종 방어선입니다.

유연한 스키마는 통제된 변화를 뜻해야 하며, 알 수 없는 변화를 뜻해서는 안 됩니다. 더 빠른 반복을 위해 MongoDB를 고르기 전에 누가 문서 형태를 책임지는지, 호환되지 않는 변경을 어떻게 감지하는지, 언제 이전 문서를 다시 쓰는지 정하세요.

쿼리, 조인, 보고

바뀌는 여러 엔터티 질문에는 PostgreSQL이 더 직접적이고, 쿼리가 하나의 문서 경계를 따를 때는 MongoDB가 간결합니다. 제품에 보고 요구 사항이 쌓일수록 쿼리의 사용성은 더 중요해집니다.

SQL은 선언적입니다. 필터, 조인, 그룹화, 공통 테이블 표현식, 윈도 함수, 하위 쿼리, 집합 연산을 저장 모델을 바꾸지 않고 조합할 수 있습니다. PostgreSQL의 플래너는 통계와 사용 가능한 인덱스를 바탕으로 조인 알고리즘과 접근 경로를 고릅니다.

정규화된 주문 데이터를 가로지르는 매출 쿼리도 읽기 쉽습니다.

SELECT
    o.customer_id,
    SUM(oi.quantity * oi.unit_price) AS revenue
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.id
WHERE o.status = 'paid'
  AND o.placed_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY o.customer_id
ORDER BY revenue DESC;

MongoDB는 단순 조회에는 직접적인 find 작업을 쓰고, 변환에는 집계 파이프라인을 씁니다. 주문 항목을 내장했다면 비슷한 계산은 문서를 순서가 있는 단계로 처리합니다.

db.orders.aggregate([
  { $match: { status: "paid", placedAt: { $gte: startDate } } },
  { $unwind: "$items" },
  {
    $group: {
      _id: "$customerId",
      revenue: { $sum: { $multiply: ["$items.quantity", "$items.unitPrice"] } }
    }
  },
  { $sort: { revenue: -1 } }
])

파이프라인 기능은 강력하지만 단계 순서는 의미와 리소스 사용량에 영향을 줍니다. 큰 배열은 $unwind 뒤에 작업 집합을 크게 늘릴 수 있습니다. 일찍 필터링하고 필요한 필드만 남기면 비용을 줄일 수 있습니다.

MongoDB의 $lookup은 다른 컬렉션의 문서를 조인합니다. 조인 대상에 인덱스가 있고 결과가 작게 유지될 때, 특히 선택된 관계에 유용합니다. 일반 요청에 여러 $lookup 단계가 필요하다면 모델 경계가 관계형일 수 있다는 신호입니다.

대부분의 보고 도구가 SQL을 사용하므로 PostgreSQL은 보통 비즈니스 인텔리전스, 재무 보고서, 코호트 분석, 계획되지 않은 질문에 더 쉽습니다. 차원이 이미 함께 있거나 준비된 읽기 모델이 보고서와 맞을 때 MongoDB 보고도 잘 작동합니다. 즉석 분석이 잦은 팀은 기본 데이터베이스와 관계없이 운영 데이터를 데이터 웨어하우스로 내보내는 경우가 많습니다.

객체 매핑으로 이런 차이가 사라지지는 않습니다. ORM은 PostgreSQL 행을 객체처럼 느끼게 할 수 있고, 객체 문서 매퍼는 MongoDB 문서에 클래스를 적용할 수 있습니다. 저장된 관계, 인덱스, 무결성 규칙이 부하 상황의 동작을 계속 결정합니다.

트랜잭션과 동시성

여러 행과 테이블에 걸친 트랜잭션에는 PostgreSQL이 가장 자연스러운 모델을 제공하고, MongoDB는 단일 문서 변경에 가장 저렴한 원자적 경계를 제공하며 필요할 때 더 넓은 트랜잭션도 지원합니다. 올바른 선택은 동시 요청에도 유지되어야 하는 불변 조건을 따릅니다.

PostgreSQL은 다중 버전 동시성 제어를 사용합니다. 일반 읽기와 쓰기는 동시에 진행할 수 있지만, 행 잠금, 명시적 잠금, 오래 실행되는 트랜잭션, 스키마 변경은 대기를 만들 수 있습니다. 기본 격리 수준은 Read Committed입니다. Repeatable Read는 안정적인 트랜잭션 스냅샷을 제공하고, Serializable은 안전하게 순서를 정할 수 없는 실행을 감지합니다.

MongoDB에서 하나의 문서를 수정하는 작업은 원자적입니다. 그래서 크기가 제한된 집합을 내장하면 조정 작업이 줄어듭니다. MongoDB는 복제본 세트와 샤딩 클러스터에서 ACID 다중 문서 트랜잭션도 지원합니다. 이런 트랜잭션은 조정 비용이 들고 실행 중 리소스를 유지하며, 애플리케이션이 전체 트랜잭션을 재시도해야 하는 일시적 실패를 일으킬 수 있습니다.

MongoDB는 read concern, write concern, read preference를 각각 제공합니다. 이 설정은 읽기가 관찰할 수 있는 데이터, 쓰기를 확인해야 하는 복제본 세트 멤버 수, 읽기가 보조 노드로 갈 수 있는지를 바꿉니다. 지연 시간 제어로 보기 전에 정확성 설정으로 다루세요.

어느 데이터베이스도 외부 결제 제공업체를 로컬 데이터베이스 트랜잭션에 넣을 수는 없습니다. 네트워크 요청을 하는 동안 트랜잭션을 열어 두면 경합이 늘고 두 시스템을 원자적으로 커밋할 수도 없습니다. 더 안전한 결제 워크플로는 하나의 데이터베이스 트랜잭션에서 보류 주문과 아웃박스 이벤트를 기록하고, 외부 요청을 멱등하게 처리한 다음 결과를 기록합니다.

동시성 테스트는 성공한 요청만이 아니라 비즈니스 경쟁 상태를 겨냥해야 합니다. 예를 들어 두 구매자가 마지막 상품을 예약하거나, 두 작업자가 같은 작업을 가져가거나, 두 관리자가 같은 고유 이름을 할당하는 경우가 있습니다. PostgreSQL은 제약 조건, 행 잠금, 원자적 문장으로 이런 작업을 자주 표현할 수 있습니다. MongoDB에서는 조건부 업데이트, 고유 인덱스, 트랜잭션을 사용할 수 있습니다.

엄격한 규칙이 독립적으로 저장된 많은 레코드에 걸친다면 PostgreSQL은 보통 애플리케이션 조정이 덜 필요합니다. 각 규칙이 잘 설계된 하나의 문서에 들어맞는다면 MongoDB의 원자적 문서 작업은 단순하고 효과적입니다.

중간 선택지로서의 PostgreSQL JSONB

안정적인 관계형 필드가 제한된 수의 변화하는 속성을 둘러싼다면 PostgreSQL JSONB는 강력한 선택지입니다. 문서형 문제를 모두 관계형 문제로 바꾸지는 않지만, 두 번째 데이터베이스가 필요 없게 만들 수 있습니다.

일반적인 설계는 식별자, 소유권, 상태, 타임스탬프를 타입이 있는 열에 저장하고 선택 속성은 jsonb에 둡니다. 외래 키가 관계를 보호하고, 일반 인덱스가 자주 쓰는 필터를 지원하며, GIN 또는 표현식 인덱스가 선택한 JSON 조건을 빠르게 처리합니다.

CREATE TABLE products (
    id bigint PRIMARY KEY,
    account_id bigint NOT NULL REFERENCES accounts(id),
    sku text NOT NULL,
    status text NOT NULL,
    attributes jsonb NOT NULL DEFAULT '{}'::jsonb,
    UNIQUE (account_id, sku)
);

CREATE INDEX products_attributes_gin
    ON products USING gin (attributes);

이 방식은 제품 유형마다 다른 소재, 치수, 지역 메타데이터 같은 카탈로그 속성에 적합합니다. 중요한 필드가 모두 JSON에 묻혀 있고 모든 쿼리에 형 변환, 경로 표현식, 사용자 지정 검증이 필요하다면 적합하지 않습니다.

JSONB는 파싱된 이진 표현을 저장하고 포함 연산자를 지원하며 객체 속성 순서처럼 의미 없는 서식을 버립니다. 중복된 객체 속성은 하나의 값만 유지합니다. 원본 JSON 텍스트를 정확히 재현해야 하는 애플리케이션은 그 텍스트를 별도로 보관해야 합니다.

작은 속성을 업데이트해도 새 PostgreSQL 행 버전이 만들어지고 상당한 크기의 JSONB 값이 다시 기록될 수 있습니다. 크고 자주 업데이트되는 문서는 많은 쓰기 전 로그와 죽은 튜플을 만들 수 있습니다. 자주 바뀌는 필드를 열이나 자식 테이블로 나누는 편이 더 좋은 성능을 내는 경우가 많습니다.

임의의 JSON 안에 숨은 관계를 외래 키가 직접 강제할 수는 없습니다. 자주 조회, 조인, 정렬, 제약하는 값은 열로 올리세요. 점진적 전환에서는 생성 열과 표현식 인덱스가 도움이 될 수 있지만, 의미가 안정되면 관계형 필드가 보통 더 명확합니다.

인덱싱과 쿼리 계획

두 데이터베이스 모두 실제 필터, 정렬, 카디널리티에 맞는 인덱스에 의존합니다. 무분별한 인덱싱은 쓰기를 느리게 하고 메모리를 소모합니다. 엔진마다 인덱스 도구는 다르지만, 저장 모델과 맞지 않는 접근 패턴을 어느 쪽도 구제할 수는 없습니다.

PostgreSQL은 동등성, 범위, 정렬된 조회에 B-tree 인덱스를 사용합니다. GIN 인덱스는 JSONB 포함, 배열, 전문 검색을 지원합니다. GiST와 SP-GiST는 여러 기하, 범위, 특수 연산자 클래스를 지원합니다. BRIN 인덱스는 시간처럼 값과 물리적 순서가 연관된 매우 큰 테이블에 적합한 작은 인덱스입니다.

PostgreSQL은 부분 인덱스와 표현식 인덱스도 지원합니다. 활성 구독에 대한 부분 인덱스는 수년치 비활성 레코드를 모두 포함하는 인덱스보다 훨씬 작을 수 있습니다. 표현식 인덱스는 정규화된 이메일 주소나 선택한 JSON 속성을 지원할 수 있습니다.

MongoDB는 중첩 속성과 배열을 직접 인덱싱합니다. 다중 키 인덱스는 배열 값을 인덱스 항목으로 확장하므로 멤버십 쿼리를 효율적으로 만들지만 인덱스가 빠르게 커질 수 있습니다. 복합 다중 키 인덱스는 같은 문서에서 배열 값 필드를 둘 이상 인덱싱할 수 없습니다. MongoDB는 각 접근 패턴에 맞게 공간, 해시, 와일드카드, 부분, 희소, TTL 인덱스도 제공합니다.

복합 인덱스의 열 순서는 보편적인 «선택도가 가장 높은 필드 우선» 규칙이 아니라 쿼리 구조를 따릅니다. PostgreSQL 다중 열 B-tree에서는 앞쪽 열의 동등 조건과 그다음 열의 범위 조건이 효율적인 스캔을 제공하는 경우가 많습니다. MongoDB에서는 흔히 동등 필드, 정렬 필드, 범위 필드 순서로 시작하되, 실제 분포에서 다른 순서가 더 적은 항목을 스캔하는지 확인합니다.

가정보다 쿼리 계획을 사용하세요.

• PostgreSQL에서는 대표적인 읽기에 EXPLAIN (ANALYZE, BUFFERS)를 실행하고 행 추정치, 루프, 정렬, 디스크 스필, 버퍼 활동을 살피세요.
• ANALYZE는 문장을 실제로 실행하므로 쓰기와 운영 트래픽에서는 주의하세요.
• MongoDB에서는 실행 통계를 요청하고 검사한 문서 수, 검사한 인덱스 항목 수, 반환한 결과 수를 비교하세요.
• 일반적인 매개변수 값뿐 아니라 데이터의 큰 비중을 차지하는 편향된 값도 테스트하세요.
• 주기적 작업, 관리 작업, 장애 조치 워크로드에서 사용하지 않는 것을 확인한 뒤에만 미사용 인덱스를 제거하세요.

한 엔드포인트를 완벽하게 처리하는 인덱스가 다른 인덱스와 중복되거나 모든 쓰기를 늘릴 수 있습니다. 인덱스 하나씩 독립적으로 승인하지 말고 전체 인덱스 집합을 포트폴리오로 검토하세요.

검색, 공간, 시계열 워크로드

두 데이터베이스 모두 기본 검색, 위치, 시간 기반 쿼리를 다루지만, 특화된 제품 요구 사항에는 별도 도구나 관리형 기능이 타당할 수 있습니다. 관련성 품질, 수집 속도, 보존 기간, 운영 책임을 기준으로 결정하세요.

PostgreSQL 전문 검색은 토큰화, 사전, 가중 문서 벡터, 쿼리 연산자, 순위, GIN 가속을 제공합니다. 코퍼스와 관련성 규칙을 관리 가능한 수준으로 유지할 수 있을 때 애플리케이션 내부 검색에 잘 맞습니다. 트라이그램 인덱스는 이름이나 식별자의 유사도 및 부분 문자열 검색을 지원할 수 있습니다.

MongoDB 텍스트 인덱스는 기본적인 단어 검색을 처리합니다. MongoDB의 관리형 플랫폼은 더 풍부한 관련성과 검색 워크로드를 위해 설계된 별도의 검색 및 벡터 검색 기능도 제공합니다. 이식성, 가격, 백업 동작, 로컬 개발을 비교할 때는 배포별 서비스로 다루세요.

벡터 검색은 트랜잭션 진실 공급원이 필요 없게 만드는 것이 아니라 쿼리 유형을 바꿉니다. PostgreSQL은 확장 기능으로 벡터 인덱싱을 추가할 수 있고, MongoDB 배포는 운영 문서를 지원되는 벡터 검색 서비스와 연결할 수 있습니다. 애플리케이션 자체 임베딩으로 재현율, 필터링, 인덱스 구축 시간, 업데이트 반영 시점, 비용을 평가하세요.

공간 작업에는 PostgreSQL이 고급 지오메트리, 좌표계, 공간 분석을 위해 PostGIS 확장을 흔히 사용합니다. MongoDB는 위치 인식 애플리케이션 쿼리에 맞는 공간 인덱스와 연산자를 제공합니다. 실제 작업 목록을 작성한 뒤에만 더 단순한 선택지를 고르세요. 가까운 점을 찾는 일은 폴리곤 복구나 복잡한 공간 조인보다 훨씬 덜 까다롭습니다.

MongoDB 시계열 컬렉션은 측정값을 내부 버킷으로 구성하고 시간 기반 만료를 지원합니다. PostgreSQL은 파티셔닝, BRIN 인덱스, 선택적 확장 기능으로 시계열 데이터를 처리합니다. 장기 보존과 광범위한 스캔이 트랜잭션 업데이트보다 중요하다면, 매우 높은 볼륨의 텔레메트리는 수집 후 전용 분석 저장소에 두는 편이 나을 수 있습니다.

성능과 대표적인 벤치마크

데이터 배치, 인덱스 적용 범위, 작업 집합 크기, 내구성 설정은 보통 일반적인 MongoDB와 PostgreSQL 벤치마크 결과보다 더 중요합니다. 신뢰할 수 있는 테스트는 애플리케이션의 데이터 분포와 동시성을 재현합니다.

하나의 요청이 하나의 인덱싱된 문서에 대응하면 MongoDB는 낮은 지연 시간의 읽기를 낼 수 있습니다. 문서가 크거나 응답에 흩어진 필드 몇 개만 필요하거나 관계에 반복 조회가 필요하면 이 이점은 줄어듭니다. 내장 배열은 인덱스 항목 수를 늘리고 업데이트 비용을 계속 높일 수도 있습니다.

통계가 정확하고 조인 열에 인덱스가 있으면 PostgreSQL은 복잡한 조인을 효율적으로 실행할 수 있습니다. 쿼리가 큰 중간 결과를 만들거나, 정렬 또는 해시를 디스크로 스필하거나, 관련 없는 많은 페이지를 반복해서 가져오면 성능이 떨어집니다. SQL 문법을 고쳐 쓰는 것보다 필요한 열만 선택하고 데이터 모델의 실수를 바로잡는 편이 더 중요한 경우가 많습니다.

보조 인덱스는 두 시스템 모두에서 쓰기 작업을 늘립니다. 큰 JSONB 값, 넓은 행, 과도하게 큰 문서, 중복된 비정규화 데이터는 I/O를 늘립니다. 개별 쿼리가 빨라도 연결 폭증은 리소스를 소진할 수 있으므로, 제한된 풀을 사용하고 장애 조치 중 재연결 동작을 테스트하세요.

유용한 벤치마크는 다음 조건을 보존해야 합니다.

• 작업 집합과 가용 메모리의 예상 비율을 나타낼 만큼 데이터를 로드하세요.
• 운영 환경의 일관성, 저널링, 복제, 확인 설정을 맞추세요.
• 현실적인 읽기와 쓰기 비율로 주요 애플리케이션 작업을 재생하세요.
• 편향, 과부하 테넌트, 큰 계정, 누락된 레코드, 최악의 필터를 포함하세요.
• 안정적인 부하와 복구 이벤트 중 처리량과 p50, p95, p99 지연 시간을 기록하세요.

한 번에 하나의 통제된 변경만 수행하세요. 하드웨어와 요청 의미를 고정한 상태에서 정규화된 테이블과 JSONB, 내장 문서와 참조, 다른 인덱스를 비교하세요. 캐시가 따뜻한 상태의 마이크로벤치마크는 백업 부하, 복제 지연, 체크포인트 동작, 기본 노드 실패 후 성능을 예측할 수 없습니다.

용량 계획에는 데이터와 인덱스 모두의 증가를 포함해야 합니다. 출시 시 메모리에 들어가던 인덱스가 1년 뒤에는 지연 시간을 좌우할 수 있습니다. 빈 데이터베이스에서 추정하지 말고 예상 데이터 규모로 테스트를 반복하세요.

수평 확장과 데이터 분포

MongoDB는 쓰기를 분산하는 통합 샤딩을 제공하고, PostgreSQL은 보통 별도의 분산 아키텍처를 채택하기 전에 수직 확장, 파티셔닝, 복제본을 결합합니다. 수평 확장은 모든 쿼리에 영향을 주는 라우팅과 소유권 결정을 수반합니다.

MongoDB 샤딩 클러스터는 샤드 키에 따라 문서를 분산합니다. 좋은 샤드 키는 충분한 카디널리티를 갖고, 단조롭게 쓰기를 한곳에 몰지 않으며, 일반적인 라우팅 조건을 지원하고, 저장소를 고르게 분산합니다. 샤드 키를 빼고 쿼리하면 모든 샤드에 접속하게 되어 지연 시간과 리소스 사용량이 늘 수 있습니다.

해시 샤딩은 순차 식별자를 더 고르게 분산할 수 있지만 범위 지역성을 약화합니다. 범위 기반 샤딩은 특정 구간을 대상으로 할 수 있지만 범위의 끝이 과부하 지점이 될 수 있습니다. 영역은 테넌트 또는 지리 규칙에 따라 선택한 범위를 지정 샤드에 배치할 수 있습니다. 리샤딩으로 잘못된 선택을 고칠 수는 있지만, 대규모 운영 데이터 세트를 옮기려면 계획과 여유 용량이 필요합니다.

MongoDB 트랜잭션은 샤드에 걸칠 수 있지만 여러 샤드 조정은 하나의 샤드로 라우팅되는 작업보다 비용이 큽니다. 테넌트 식별자를 샤드 키와 일반 쿼리에 모두 넣는 애플리케이션은 관련 작업을 같은 위치에 두는 경우가 많습니다.

PostgreSQL 네이티브 파티셔닝은 논리 테이블을 보통 시간, 테넌트 또는 다른 라우팅 값에 따라 자식 테이블로 나눕니다. 파티션 제거는 스캔을 줄이고 파티션은 보존 작업을 단순하게 합니다. 네이티브 파티셔닝만으로는 여러 장비에 쓰기를 분산하지 않으므로 샤딩이라고 설명해서는 안 됩니다.

PostgreSQL 읽기 복제본은 적합한 읽기 트래픽을 기본 노드에서 옮길 수 있습니다. 복제본은 기본 노드의 쓰기 용량을 늘리지 못하며 비동기 복제본은 이전 데이터를 반환할 수 있습니다. 애플리케이션은 어떤 읽기가 이 지연을 허용할 수 있는지 정해야 합니다.

PostgreSQL 작성자 하나로 부족해지면 팀은 애플리케이션 코드에서 샤딩하거나, 분산 PostgreSQL 확장 또는 서비스를 도입하거나, 영역을 독립 소유 데이터베이스로 나눌 수 있습니다. 각 선택지는 샤드 간 조인, 고유성, 시퀀스, 트랜잭션의 동작을 바꿉니다. 애플리케이션이 전역 작업에 의존하기 전에 이런 제약을 테스트하세요.

확장 요구 사항은 숫자로 표현해야 합니다. 예상 초당 쓰기 작업 수, 데이터 세트 크기, 과부하 테넌트 집중도, 리전 배치, 복구 목표가 단순한 수평 확장 요구보다 더 유용합니다.

복제, 장애 조치, 복구

두 데이터베이스 모두 고가용성을 제공할 수 있지만, 복구 동작은 토폴로지, 확인 정책, 자동화, 반복 테스트에 달려 있습니다. 복제만으로 짧은 중단 시간이나 데이터 손실 없음이 보장되지는 않습니다.

MongoDB는 보통 기본 노드 하나와 보조 노드 여러 개로 구성된 복제본 세트로 운영됩니다. 현재 기본 노드를 사용할 수 없으면 멤버들이 새 기본 노드를 선출합니다. 애플리케이션은 지원되는 드라이버를 사용하고 서버 선택 및 작업 시간 제한을 구성하며 일시적 오류를 처리해야 합니다. 재시도 가능 쓰기는 일부 작업에 도움이 되지만 재시도도 애플리케이션 멱등성을 지켜야 합니다.

write concern은 쓰기를 확인하는 멤버 수를 제어합니다. read preference는 적격 읽기가 기본 노드 또는 보조 노드를 쓸지 정하고, read concern은 가시성 보장을 제어합니다. 낮은 지연 시간 구성은 실패 또는 오래된 데이터의 위험을 더 노출할 수 있으므로 워크로드별로 선택한 조합을 문서화하세요.

PostgreSQL 물리 스트리밍 복제는 기본 노드에서 대기 노드로 쓰기 전 로그 레코드를 보냅니다. 비동기 복제는 가용성과 지연 시간을 보호하지만, 대기 노드가 받기 전에 기본 노드가 파괴되면 최근에 확인된 트랜잭션을 잃을 수 있습니다. 동기 복제는 이 위험을 줄일 수 있지만 커밋 지연 시간과 대기 노드 상태에 대한 민감도를 높입니다.

PostgreSQL 장애 조치는 보통 관리형 서비스나 외부 자동화가 조정합니다. 절차는 적절한 대기 노드를 승격하고, 클라이언트 방향을 바꾸며, 이전 기본 노드가 충돌하는 쓰기를 받지 못하게 해야 합니다. 연결 풀과 DNS 캐시는 승격 후 체감 중단 시간을 늘릴 수 있습니다.

백업은 실수로 인한 삭제와 논리적 손상처럼 복제가 충실히 복사하는 실패로부터 보호합니다. PostgreSQL 기본 백업과 보관된 쓰기 전 로그로 특정 시점 복구를 할 수 있습니다. MongoDB 배포는 적절한 도구나 관리형 서비스를 통해 조정된 스냅샷과 oplog 기반 복구를 사용할 수 있습니다.

복구 시점 목표와 복구 시간 목표를 별도로 정하세요. 그다음 격리된 환경에 전체 복원을 테스트하고, 애플리케이션 데이터를 검증하고, 복원된 자격 증명을 교체하고, 경과 시간을 기록하세요. 스냅샷이 성공했다고 해서 목표 시간 안에 전체 서비스를 복구할 수 있다는 증거는 아닙니다.

운영 유지보수

PostgreSQL과 MongoDB는 일상 유지보수가 다르므로 팀 경험이 작은 기능상 이점보다 더 중요할 수 있습니다. 관리형 서비스는 일부 수고를 줄이지만 쿼리 설계, 용량 결정, 복구 검증까지 맡아 주지는 않습니다.

PostgreSQL은 트랜잭션이 데이터를 업데이트하거나 삭제할 때 오래된 행 버전을 만듭니다. 자동 정리는 재사용 가능한 공간을 회수하고 가시성 정보를 갱신하며 트랜잭션 ID 고갈을 방지합니다. 오래 실행되는 트랜잭션은 정리를 늦출 수 있습니다. 죽은 튜플, 테이블과 인덱스 증가, vacuum 진행 상황, 트랜잭션 수명, 이전 스냅샷을 유지하는 쿼리를 모니터링하세요.

플래너 통계도 관리가 필요합니다. 편향된 값이나 상관관계가 있는 열은 부정확한 행 추정과 좋지 않은 계획을 만들 수 있습니다. 통계 목표를 높이거나 확장 통계를 만들면 선택한 쿼리에 도움이 됩니다. 큰 데이터 증가 뒤에도 쿼리 성능을 검토해야 하며 코드 변경 뒤에만 검토해서는 안 됩니다.

MongoDB의 WiredTiger 스토리지 엔진은 캐시와 압축에 크게 의존합니다. 캐시 압박, 디스크 지연 시간, 문서 증가, 체크포인트 동작, 복제 지연, 검사한 문서와 반환한 문서의 비율을 모니터링하세요. 샤딩 배포에서는 밸런싱 활동, 고르지 않은 청크 분포, 여러 샤드에 흩어지는 작업도 확인하세요.

일상 운영 절차는 다섯 영역을 다뤄야 합니다.

• 느린 쿼리 수집, 담당자, 해결 기준
• 현재 사용량만이 아니라 증가율을 바탕으로 한 용량 경고
• 복구 시간과 검증 단계를 기록하는 복원 훈련
• 자격 증명 교체와 비상 접근 절차
• 드라이버, 확장 기능, 인덱스, 롤백 계획을 대상으로 테스트한 버전 업그레이드

PostgreSQL 주요 업그레이드에는 보통 pg_upgrade, 논리 복제, 관리형 마이그레이션 절차를 사용합니다. 확장 기능 호환성이 가능한 경로를 결정할 수 있습니다. MongoDB 업그레이드는 지원되는 버전 순서와 Feature Compatibility Version 제어를 사용하며, 샤딩 클러스터는 구성 요소 순서에 주의해야 합니다.

pg_dump와 mongodump 같은 논리 내보내기 도구는 더 작은 데이터 세트와 선택적 복구에 편리합니다. 대규모에서 엄격한 복구 목표를 충족하기에는 너무 느릴 수 있습니다. 이를 주 재해 복구 방식으로 채택하기 전에 운영 규모 데이터로 내보내기와 가져오기 시간을 측정하세요.

보안과 거버넌스

두 데이터베이스 모두 접근, 암호화, 감사, 네트워크 제어를 명시적으로 설계하면 엄격한 보안 요구 사항을 충족할 수 있습니다. 기본 자격 증명이나 사설 네트워킹만으로 감사 가능한 시스템이 만들어지지는 않습니다.

PostgreSQL 역할에는 데이터베이스, 스키마, 테이블, 시퀀스, 함수, 열 수준의 권한을 줄 수 있습니다. 뷰로 선택한 필드를 노출할 수 있고 행 수준 보안으로 사용자 또는 테넌트 컨텍스트에 따라 행을 제한할 수 있습니다. 손상된 서비스가 자체 제한을 바꾸지 못하게 객체 소유권을 일반 애플리케이션 역할과 분리하세요.

MongoDB 역할은 데이터베이스, 컬렉션, 클러스터 리소스에 대한 작업 권한을 부여합니다. 애플리케이션 읽기, 애플리케이션 쓰기, 마이그레이션, 모니터링, 백업, 관리에 각각 다른 ID를 사용하세요. 여러 서비스에서 광범위한 권한의 자격 증명 하나를 공유하지 마세요.

실용적인 통제 항목은 다음과 같습니다.

• 클라이언트와 복제 트래픽에 TLS를 요구하고 모든 드라이버의 인증서 처리를 검증하세요.
• 비밀은 관리형 비밀 시스템에 저장하고 전체 애플리케이션 릴리스 없이 교체하세요.
• 네트워크 경로를 제한하고 데이터베이스 리스너를 공용 인터넷에 직접 노출하지 마세요.
• 정책이 요구하는 인증, 권한, 스키마, 민감 데이터 접근 이벤트를 기록하세요.
• 분석가, 지원 인력, 자동화 계정이 맡은 역할을 넘지 못하는지 테스트하세요.

저장 시 암호화는 데이터베이스 기능, 암호화된 스토리지, 클라우드 관리 키를 결합할 수 있습니다. MongoDB는 지원되는 배포에서 클라이언트 측 필드 수준 암호화도 지원합니다. PostgreSQL 애플리케이션은 데이터베이스 관리자가 평문을 보면 안 될 때 선택한 값을 저장 전에 흔히 암호화합니다. 암호화는 인덱싱과 쿼리 옵션을 바꾸므로 먼저 보호할 작업을 프로토타입으로 검증하세요.

거버넌스에는 데이터 분류, 보존, 삭제, 소재지, 사고 대응 절차도 필요합니다. 리전 배치는 소재지 목표를 뒷받침할 수 있지만, 규정 준수는 백업, 로그, 지원 접근, 하위 처리자, 데이터를 받는 모든 시스템에 달려 있습니다.

비용, 라이선스, 총소유비용

더 저렴한 데이터베이스는 허용 가능한 인프라, 서비스 요금, 엔지니어링 노력으로 워크로드를 충족하는 데이터베이스입니다. 라이선스 가격만으로 총소유비용이 결정되는 일은 드뭅니다.

컴퓨팅 비용은 복잡한 쿼리, 압축 작업, 인덱스 유지보수, 백그라운드 작업, 복제로 증가합니다. 스토리지에는 인덱스, 보존 로그, 백업, 임시 공간, 비정규화로 생긴 중복 데이터가 포함됩니다. 데이터가 있는 복제본 세 개는 스냅샷과 리전 간 전송을 계산하기 전부터 여러 복사본을 저장합니다.

PostgreSQL은 허용적인 PostgreSQL License를 사용하며 자체 호스팅과 관리형 배포 방식이 다양합니다. 상용 지원과 클라우드 서비스는 선택 구매 항목입니다. 확장 기능은 자체 라이선스를 가질 수 있으므로 별도로 검토하세요.

MongoDB Community Server는 Server Side Public License를 사용합니다. 소스는 이용할 수 있지만 Open Source Initiative가 승인한 라이선스는 아닙니다. MongoDB Atlas와 상용 지원에는 공급업체 가격과 약관이 적용됩니다. 데이터베이스 기능을 서비스에 내장하거나 제공하는 조직은 허용적인 오픈 소스 라이선스와 같다고 가정하지 말고 법률 자문을 통해 해당 약관을 검토해야 합니다.

관리형 데이터베이스는 자동 프로비저닝, 패치, 백업, 모니터링 연동, 장애 조치 절차 일부를 위해 단가를 더 받습니다. 그래도 스키마 품질, 느린 쿼리, 연결 관리, 데이터 분류, 애플리케이션 복구는 고객의 책임입니다.

다음 입력값으로 총소유비용을 추정하세요.

• 운영, 스테이징, 개발, 재해 복구, 임시 환경의 수
• 최소 향후 12~24개월 동안의 데이터와 인덱스 증가
• 필요한 복제본, 리전, 백업 보존 기간, 네트워크 전송
• 최대 처리량, 작업 집합 메모리, 프로비저닝된 스토리지 성능
• 마이그레이션, 튜닝, 장애 대응, 감사, 복원 훈련에 드는 인력 시간

팀이 이미 잘 지원하는 데이터베이스는 기술적으로 매력적인 대안보다 저렴할 수 있습니다. 교육, 새 자동화, 변경된 온콜 절차, 마이그레이션 위험도 실제 비용입니다.

워크로드별 애플리케이션 적합성

관계가 많은 기록 시스템에서는 PostgreSQL이 더 강력한 기본 선택이고, 독립적으로 소유되는 가변 문서 영역에서는 MongoDB가 가치를 발휘합니다. 웹 애플리케이션이나 엔터프라이즈 시스템 같은 넓은 라벨보다 구체적인 워크플로가 적합성을 더 잘 드러냅니다.

SaaS 계정 모델에는 보통 조직, 멤버십, 초대, 역할, 구독, 청구서, 권한, 감사 레코드가 포함됩니다. 고유성과 엔터티 간 규칙이 핵심이고, 관리자는 결국 출시 시 예상하지 못한 보고서를 요청합니다. PostgreSQL은 이 패턴에 잘 맞습니다.

제품 카탈로그에는 의류, 전자제품, 산업 부품, 사용자 지정 테넌트 범주별로 서로 다른 속성 집합이 있을 수 있습니다. MongoDB는 희소한 범용 테이블을 만들지 않고 각 제품을 일관된 문서로 저장할 수 있습니다. 제품이 가격표, 재고 트랜잭션, 공급업체 계약, 관계형 보고에 많이 참여한다면 JSONB를 사용하는 PostgreSQL도 충분히 경쟁력 있습니다.

콘텐츠 관리 영역은 블록, 현지화, 메타데이터, 발행 상태를 담은 문서에 자연스럽게 맞는 경우가 많습니다. 항목 하나를 단위로 읽고 수정한다면 MongoDB가 잘 작동합니다. 편집 권한, 일정 관리, 콘텐츠 간 참조, 보고가 문서 변화보다 더 까다롭다면 PostgreSQL이 더 나을 수 있습니다.

재무 원장, 재고 예약, 청구 레코드는 PostgreSQL에 유리합니다. 추가 전용 설계만으로 고유성, 균형 잡힌 항목, 대사 쿼리, 여러 레코드에 걸친 불변 조건이 필요한 문제가 사라지지는 않습니다.

이벤트와 텔레메트리 시스템은 더 자세한 테스트가 필요합니다. MongoDB는 문서 형태 이벤트를 수집할 수 있고 PostgreSQL은 추가가 많은 테이블을 파티셔닝할 수 있습니다. 지속적인 분석 규모에서는 운영 데이터베이스가 열 지향 웨어하우스나 전용 시계열 시스템에 데이터를 보낼 수 있습니다. 보존 기간, 집계 윈도우, 늦게 도착하는 데이터, 쿼리 스캔 크기로 저장 경로를 결정하세요.

권위 있는 엔터티가 PostgreSQL에 남고 문서 영역이 별도의 소유권과 접근 패턴을 가질 때 하이브리드 아키텍처가 타당합니다. 엔터티마다 하나의 진실 공급원을 지정하세요. 아웃박스나 변경 데이터 캡처 프로세스로 변경을 발행하고, 멱등성 소비자를 쓰며, 지연되거나 중복된 전달을 계획하세요. 부분 실패 후 두 저장소를 불일치 상태로 남길 수 있는 동기식 이중 쓰기는 피하세요.

실용적인 의사 결정 방법

운영 환경과 비슷한 형태의 데이터로 진행하는 짧은 개념 검증은 박빙의 MongoDB와 PostgreSQL 결정을 해결하는 가장 신뢰할 수 있는 방법입니다. 일반적인 생성, 읽기, 업데이트, 삭제 데모보다 어려운 부분에 집중해야 합니다.

가장 흔한 요청, 가장 복잡한 쿼리, 정확성 요구가 가장 엄격한 작업이라는 대표 워크플로 세 가지를 고르세요. 두 데이터베이스에서 각 워크플로를 솔직하게 모델링하세요. PostgreSQL에 제한 없는 JSON 열 하나로 문서 저장소를 흉내 내게 하지 말고, MongoDB에 많은 컬렉션에 걸친 고도로 정규화된 스키마를 재현하게 하지 마세요.

모델 명확성, 정확성, 쿼리 노력, 측정된 지연 시간, 운영 친숙도, 복구, 보안 제어, 예상 비용으로 각 후보를 평가하세요. 벤치마크 결과를 보기 전에 범주의 가중치를 정하세요. 재무 애플리케이션은 마이그레이션 회피보다 무결성과 감사 가능성에 더 큰 비중을 두어야 하고, 일회성 콘텐츠 프로토타입은 반대로 할 수 있습니다.

다음 가정 중 하나에 의존한다면 설계를 거부하세요.

• 앞으로의 모든 쿼리가 첫 API의 접근 패턴을 따를 것이다.
• 애플리케이션 검증이 모든 쓰기 경로에서 영원히 정확히 실행될 것이다.
• 하나의 대형 테넌트가 중간값 테넌트처럼 동작할 것이다.
• 복제가 백업과 복원 훈련의 필요성을 없앤다.
• 두 번째 데이터베이스는 첫 배포가 관리형이므로 운영 비용이 거의 없다.

일반적인 트랜잭션 애플리케이션이라면 PostgreSQL이 더 안전한 출발점입니다. 테이블, SQL, 제약 조건, 성숙한 트랜잭션 모델, JSONB 지원은 구조화된 데이터와 선택한 반정형 데이터 모두를 다룰 여지를 남깁니다. 마이그레이션이 불편해 보인다는 이유가 아니라, 문서 모델이 실질적으로 더 단순한 설계를 만들거나 통합 분산 모델이 측정한 요구 사항에 맞을 때 MongoDB를 선택해야 합니다.

Koder.ai 프로젝트에 선택 적용하기

Koder.ai의 기본 스택은 React, Go, PostgreSQL, 모바일 애플리케이션용 Flutter이므로 대부분의 Koder.ai 프로젝트는 PostgreSQL로 시작하는 것이 자연스럽습니다. 이 기본 선택은 채팅 인터페이스로 흔히 만드는 웹사이트, CRM, ERP, 모바일 앱, 기타 트랜잭션 시스템에 잘 맞습니다.

생성에 들어가기 전에 계획 모드에서 엔터티, 관계, 고유성 규칙, 데이터 보존, 대용량 작업을 파악해야 합니다. 안정적인 속성은 타입이 있는 열에 둡니다. 구조가 실제로 가변적인 선택형 비즈니스 속성에는 JSONB를 사용할 수 있습니다.

Koder.ai는 소스 코드 내보내기, 배포와 호스팅, 사용자 지정 도메인, 스냅샷, 롤백을 지원합니다. 스냅샷과 애플리케이션 롤백은 데이터베이스 마이그레이션 계획을 보완해야 하며 대체해서는 안 됩니다. 호환되지 않는 스키마 변경 뒤에 애플리케이션 코드를 되돌리면 이전 코드가 새로 기록된 데이터를 읽지 못할 수 있습니다.

생성된 Go 서비스에서는 데이터베이스 변경을 검토된 마이그레이션으로 관리하고 전환 기간에 배포가 안전하도록 하세요. 일반적인 순서는 호환되는 스키마를 추가하고, 두 상태를 모두 이해하는 코드를 배포하고, 데이터를 백필하고, 읽기를 전환한 뒤, 이후 릴리스에서 이전 형식을 제거하는 것입니다.

Koder.ai는 데이터 배치 요구 사항을 뒷받침하기 위해 여러 국가의 AWS 인프라에서 애플리케이션을 실행할 수 있습니다. 데이터베이스 설계는 이 결정을 복제본, 백업, 로그, 분석 내보내기, 관리 접근까지 확장해야 합니다. 지리적 배치는 더 넓은 개인정보 보호 및 거버넌스 계획 안의 하나의 통제 수단입니다.

PostgreSQL 기반 프로젝트에 MongoDB를 추가할 때는 다른 아키텍처 의존성과 같은 기준을 적용하세요. 구현 전에 문서가 소유할 영역, 실패 처리, 동기화 경로, 백업 정책, 운영자 책임을 정의하세요.

마이그레이션과 도입 체크리스트

데이터베이스 마이그레이션은 팀이 데이터 완전성, 애플리케이션 호환성, 되돌릴 수 있는 전환을 증명할 수 있을 때 성공합니다. 문법을 변환하는 일은 작업의 한 부분일 뿐입니다.

먼저 테이블 또는 컬렉션, 데이터 규모, 인덱스, 제약 조건, 쿼리 패턴, 보존 규칙, 모든 작성자를 목록화하세요. 관계형 외래 키가 참조가 되는 경우, 내장 배열이 자식 테이블이 되는 경우, 숫자 정밀도 차이, 대소문자 구분 비교, 타임스탬프 처리처럼 직접 변환되지 않는 의미를 찾으세요.

운영 데이터를 옮기기 전에 대사 쿼리를 만드세요. 개수만으로는 충분하지 않습니다. 테넌트와 날짜별 합계를 비교하고, 고유성을 검증하고, 큰 레코드를 표본 확인하고, 고아 관계를 점검하고, 해당한다면 비즈니스 수준의 잔액을 계산하세요.

통제된 마이그레이션은 보통 다음 단계를 포함합니다.

• 초기 대량 복사를 수행하고 거부되거나 변환된 레코드를 기록합니다.
• 로그, 아웃박스, 변경 데이터 캡처 메커니즘으로 이후 변경을 수집합니다.
• 사용자에게 보이는 동작을 바꾸지 않고 섀도 읽기를 하거나 표본 응답을 비교합니다.
• 오류와 지연을 모니터링하면서 되돌릴 수 있는 라우팅 변경으로 전환합니다.
• 대사와 롤백 기간이 끝날 때까지 기존 저장소를 읽기 전용으로 유지합니다.

애플리케이션 코드의 이중 쓰기는 두 쓰기가 모두 멱등적이고 부분 실패를 명시적으로 대사하지 않는 한 위험합니다. 재시도할 수 있는 비동기 전달 레코드가 있는 하나의 커밋된 원본을 우선하세요.

전환 뒤에는 운영 기준선을 다시 세우세요. 이전 엔진의 쿼리 계획, 연결 풀 크기, 경고 기준, 백업 기간, 용량 예측은 자동으로 옮겨지지 않습니다. 새 데이터베이스가 복원 훈련을 통과하고 팀이 장애 중에도 운영할 수 있을 때 비로소 마이그레이션이 끝납니다.