본문 바로가기
Q&A해결2026년 4월 24일1분 읽기

MongoDB 8 vs PostgreSQL 18에서 multi-tenant 1만 테이블 어떤 게 더 나은가요?

S
SaaS창업자
조회 923댓글 1

SaaS B2B 제품을 준비 중입니다. tenant당 schema 분리 방식으로 갈지, single schema + tenant_id 컬럼 분리로 갈지 고민입니다.

예상 tenant 수는 1만 정도, 각 tenant 데이터는 100MB~10GB 사이 분산입니다. PostgreSQL 18 vs MongoDB 8 둘 중 어떤 게 적합할까요? 운영 측면도 함께 알려주세요.

MongoDBPostgreSQLMulti-tenantSchema
이전 글
Terraform 1.11 업그레이드 후 state lock이 무한 대기에 걸립니다
다음 글
RAG에서 한국어 임베딩 정확도가 떨어집니다 — bge-m3 vs Cohere v4
관련 글
MySQL 8.4 LTS Group Replication에서 split-brain이 발생합니다2026. 4. 23.pgvector 0.10으로 올렸더니 HNSW 검색 결과가 0.9 때와 달라졌습니다2026. 4. 21.PostgreSQL vs MySQL 신규 프로젝트에 뭘 선택할까요2026. 2. 20.

댓글 1

김김영삼6개월 전

1만 tenant + GB 단위 편차 + B2B SaaS — 이 조합에서는 PostgreSQL 18 + tenant_id 컬럼 분리(single schema)가 가장 무난한 정답입니다. 이유를 단계별로 설명드립니다.

1) "schema 분리"는 1만 tenant에서 운영 지옥

tenant당 schema 분리는 100~500 tenant까지는 깔끔하지만 1만이 되면:

  • pg_dump·pg_restore가 1만 schema 순회로 시간 폭증
  • migration 한 번 = 1만 schema 순차 ALTER (시간·실수 위험)
  • connection pool 분리 부담 — 한 connection이 어느 schema인지 추적
  • shared row(예: usage tracking)가 어디 있어야 할지 매번 고민

PostgreSQL 18에서 pg_dump가 일부 빨라지긴 했지만 본질은 그대로입니다.

2) "테이블 분리(테이블당 tenant 1만)"는 더 나쁨

1만 테이블이 되면 PostgreSQL의 catalog가 비대해지고, autovacuum·analyze가 모든 테이블을 순회하면서 IO 폭증. 8.4 이전 MySQL의 file-per-table 악몽과 비슷합니다.

3) Single schema + tenant_id 컬럼 (권장)

-- 모든 테이블에 tenant_id 컬럼
CREATE TABLE invoices (
  id BIGSERIAL PRIMARY KEY,
  tenant_id UUID NOT NULL,
  amount NUMERIC,
  ...
);

CREATE INDEX ON invoices (tenant_id, created_at DESC);

-- RLS로 격리
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::UUID);

-- 애플리케이션에서
SET app.tenant_id = '...';
SELECT * FROM invoices;  -- 자동으로 격리됨

장점

  • schema 1개 — migration 1회로 끝
  • pg_dump 단순
  • RLS로 격리 자동화 (실수 방지)
  • tenant 간 통계·집계 쿼리 즉시 가능
  • connection pool 단순 (PgBouncer 한 풀로 충분)

단점·대응

  • tenant 데이터 export = WHERE tenant_id 쿼리 (어렵지 않음)
  • 일부 tenant가 비대해지면 partition으로 분할 (LIST partitioning by tenant_id 일부)

4) MongoDB가 더 나은 케이스

다음 중 둘 이상 해당되면 MongoDB 검토:

  • tenant 간 schema가 매우 다름 (custom field 자유도가 본질)
  • JSON 깊은 중첩 검색 + 빈번한 schema 변경
  • geo·timeseries 워크로드가 주류
  • RDB 풀스캔 패턴이 거의 없음

MongoDB 8은 multi-tenant에서 database-per-tenant 또는 collection 분리가 일반적이지만, 1만 collection도 운영 부담이 큽니다.

5) PostgreSQL 18의 multi-tenant 친화 기능

  • RLS 성능이 17 대비 약 30% 향상 (planner 개선)
  • partial index가 tenant_id 조건과 잘 어울림
  • logical replication으로 큰 tenant만 별도 cluster로 떼어내기 용이
  • pg_partman으로 tenant_id 기반 자동 partition 관리

6) 실무 운영 권장

  1. 모든 테이블 PK = (tenant_id, id) 복합 또는 tenant_id 별도 인덱스
  2. RLS 활성화 + middleware에서 SET app.tenant_id 강제
  3. 큰 tenant는 모니터링 — top 1% tenant가 80% 트래픽 흔함
  4. 큰 tenant 임계 도달 시 partition 분할 또는 별도 cluster 이전 자동화
  5. backup은 logical replication으로 tenant 단위 복원 가능 환경 구성

마지막 답변

"PostgreSQL 18 + single schema + tenant_id + RLS"가 1만 tenant 규모에서 가장 검증된 패턴입니다. MongoDB는 schema 자유도가 핵심 가치일 때 의미가 있고, 단순 multi-tenant 격리 목적만이라면 PostgreSQL이 압도적으로 운영 비용이 낮습니다.

Ctrl+Enter로 등록