기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# PostgreSQL용 멀티 테넌트 SaaS 파티셔닝 모델
<a name="partitioning-models"></a>

다중 테넌시를 수행하는 가장 좋은 방법은 SaaS 애플리케이션의 요구 사항에 따라 다릅니다. 다음 섹션에서는 PostgreSQL에서 다중 테넌시를 성공적으로 구현하기 위한 파티셔닝 모델을 보여줍니다.

**참고**  
이 섹션에서 설명하는 모델은 Amazon RDS for PostgreSQL 및 Aurora PostgreSQL 호환 모두에 적용됩니다. 이 섹션의 *PostgreSQL*에 대한 참조는 두 서비스 모두에 적용됩니다.

SaaS 파티셔닝을 위한 PostgreSQL에는 사일로, 브리지 및 풀이라는 세 가지 상위 수준 모델을 사용할 수 있습니다. 다음 이미지는 사일로 모델과 풀 모델 간의 장단점을 요약한 것입니다. 브리지 모델은 사일로 및 풀 모델의 하이브리드입니다.


****  

| **파티셔닝 모델** | **장점** | **단점** | 
| --- | --- | --- | 
| 사일로 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | 
| 풀 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | 
| 브리지 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | 

다음 섹션에서는 각 모델에 대해 자세히 설명합니다.

**Topics**
+ [PostgreSQL 사일로 모델](silo.md)
+ [PostgreSQL 풀 모델](pool.md)
+ [PostgreSQL 브리지 모델](bridge.md)
+ [의사결정 매트릭스](matrix.md)

# PostgreSQL 사일로 모델
<a name="silo"></a>

사일로 모델은 애플리케이션의 각 테넌트에 대해 PostgreSQL 인스턴스를 프로비저닝하여 구현됩니다. 사일로 모델은 테넌트 성능 및 보안 격리에 뛰어나며 *노이즈가 많은 이웃* 현상을 완전히 제거합니다. 시끄러운 이웃 현상은 한 테넌트의 시스템 사용이 다른 테넌트의 성능에 영향을 미칠 때 발생합니다. 사일로 모델을 사용하면 특히 각 테넌트에 맞게 성능을 조정하고 특정 테넌트의 사일로에 대한 중단을 잠재적으로 제한할 수 있습니다. 그러나 일반적으로 사일로 모델 채택을 유도하는 요인은 엄격한 보안 및 규제 제약입니다. 이러한 제약 조건은 SaaS 고객이 동기를 부여할 수 있습니다. 예를 들어 SaaS 고객은 내부 제약으로 인해 데이터를 격리하도록 요구할 수 있으며 SaaS 공급자는 추가 요금을 지불하고 이러한 서비스를 제공할 수 있습니다.

 ![\[SaaS PostgreSQL silo model\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-silo.png) 

경우에 따라 사일로 모델이 필요할 수 있지만 단점이 많습니다. 여러 PostgreSQL 인스턴스에서 리소스 소비를 관리하는 것은 복잡할 수 있으므로 사일로 모델을 비용 효율적인 방식으로 사용하기 어려운 경우가 많습니다. 또한이 모델에서 데이터베이스 워크로드의 분산 특성으로 인해 테넌트 활동에 대한 중앙 집중식 보기를 유지하기가 더 어렵습니다. 독립적으로 운영되는 워크로드를 너무 많이 관리하면 운영 및 관리 오버헤드가 증가합니다. 또한 사일로 모델을 사용하면 테넌트별 리소스를 프로비저닝해야 하므로 테넌트 온보딩이 더 복잡하고 시간이 많이 걸립니다. 또한 테넌트별 PostgreSQL 인스턴스의 수가 계속 증가하면 관리하는 데 더 많은 운영 시간이 필요하므로 전체 SaaS 시스템을 확장하기가 더 어려울 수 있습니다. 마지막 고려 사항은 애플리케이션 또는 데이터 액세스 계층이 연결된 PostgreSQL 인스턴스에 대한 테넌트 매핑을 유지해야 하므로이 모델을 구현하는 데 복잡성이 가중된다는 것입니다.

# PostgreSQL 풀 모델
<a name="pool"></a>

풀 모델은 단일 PostgreSQL 인스턴스(Amazon RDS 또는 Aurora)를 프로비저닝하고 [행 수준 보안(RLS)](https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/)을 사용하여 테넌트 데이터 격리를 유지함으로써 구현됩니다. RLS 정책은 `SELECT` 쿼리에서 반환되는 테이블의 행 또는 `INSERT`, `UPDATE`및 `DELETE` 명령의 영향을 받는 행을 제한합니다. 풀 모델은 모든 테넌트 데이터를 단일 PostgreSQL 스키마로 중앙 집중화하므로 훨씬 더 비용 효율적이며 유지 관리해야 하는 운영 오버헤드가 줄어듭니다. 이 솔루션을 모니터링하는 것도 중앙 집중화로 인해 훨씬 간단합니다. 그러나 풀 모델에서 테넌트별 영향을 모니터링하려면 일반적으로 애플리케이션에서 몇 가지 추가 계측이 필요합니다. 이는 기본적으로 PostgreSQL이 리소스를 소비하는 테넌트를 인식하지 못하기 때문입니다. 새 인프라가 필요하지 않으므로 테넌트 온보딩이 간소화됩니다. 이러한 민첩성을 통해 빠르고 자동화된 테넌트 온보딩 워크플로를 더 쉽게 수행할 수 있습니다.

 ![\[SaaS PostgreSQL pool model\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-pool.png) 

풀 모델은 일반적으로 더 비용 효율적이고 관리가 더 간단하지만 몇 가지 단점이 있습니다. 풀 모델에서는 시끄러운 이웃 현상을 완전히 제거할 수 없습니다. 그러나 PostgreSQL 인스턴스에서 적절한 리소스를 사용할 수 있는지 확인하고 읽기 전용 복제본 또는 Amazon ElastiCache로 쿼리를 오프로드하는 등 PostgreSQL의 부하를 줄이는 전략을 사용하여 완화할 수 있습니다. 또한 애플리케이션 계측은 테넌트별 활동을 로깅하고 모니터링할 수 있으므로 효과적인 모니터링은 테넌트 성능 격리 문제에 대응하는 역할을 합니다. 마지막으로 일부 SaaS 고객은 RLS에서 제공하는 논리적 분리가 충분하지 않다고 판단하여 추가 격리 조치를 요청할 수 있습니다.

# PostgreSQL 브리지 모델
<a name="bridge"></a>

PostgreSQL 브리지 모델은 풀링된 접근 방식과 사일로화된 접근 방식의 조합입니다. 풀링된 모델과 마찬가지로 각 테넌트에 대해 단일 PostgreSQL 인스턴스를 프로비저닝합니다. 테넌트 데이터 격리를 유지하려면 PostgreSQL 논리적 구문을 사용합니다. 다음 다이어그램에서 PostgreSQL 데이터베이스는 데이터를 논리적으로 구분하는 데 사용됩니다.

**참고**  
PostgreSQL 데이터베이스는 별도의 Amazon RDS for PostgreSQL 또는 Aurora PostgreSQL 호환 DB 인스턴스를 참조하지 않습니다. 대신 PostgreSQL 데이터베이스 관리 시스템의 논리적 구성을 참조하여 데이터를 구분합니다.

 ![\[SaaS PostgreSQL bridge model with separate databases\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-dbs.png) 

다음 다이어그램과 같이 각 데이터베이스의 테넌트별 스키마와 함께 단일 PostgreSQL 데이터베이스를 사용하여 브리지 모델을 구현할 수도 있습니다.

 ![\[SaaS PostgreSQL bridge model with separate schemas\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-schemas.png) 

브리지 모델은 풀 모델과 동일한 시끄러운 이웃 및 테넌트 성능 격리 문제를 겪습니다. 또한 별도의 데이터베이스 또는 스키마를 테넌트별로 프로비저닝해야 하므로 몇 가지 추가 운영 및 프로비저닝 오버헤드가 발생합니다. 테넌트 성능 문제에 신속하게 대응하려면 효과적인 모니터링이 필요합니다. 또한 테넌트별 사용량을 모니터링하려면 애플리케이션 계측이 필요합니다. 전반적으로 브리지 모델은 새로운 PostgreSQL 데이터베이스 또는 스키마를 요구하여 테넌트 온보딩 노력을 약간 강화하는 RLS의 대안으로 볼 수 있습니다. 사일로 모델과 마찬가지로 애플리케이션 또는 데이터 액세스 계층은 연결된 PostgreSQL 데이터베이스 또는 스키마에 대한 테넌트 매핑을 유지해야 합니다.

# 의사결정 매트릭스
<a name="matrix"></a>

PostgreSQL에서 사용해야 하는 멀티 테넌트 SaaS 파티셔닝 모델을 결정하려면 다음 결정 매트릭스를 참조하세요. 매트릭스는 다음 네 가지 파티셔닝 옵션을 분석합니다.
+ 사일로 - 각 테넌트에 대해 별도의 PostgreSQL 인스턴스 또는 클러스터입니다.
+ 별도의 데이터베이스가 있는 브리지 - 단일 PostgreSQL 인스턴스 또는 클러스터의 각 테넌트에 대한 별도의 데이터베이스입니다.
+ 별도의 스키마가 있는 브리지 - 단일 PostgreSQL 데이터베이스의 각 테넌트, 단일 PostgreSQL 인스턴스 또는 클러스터에 대한 별도의 스키마입니다.
+ 풀 - 단일 인스턴스 및 스키마의 테넌트에 대한 공유 테이블입니다.


****  

| **** | **사일로** | **별도의 데이터베이스가 있는 브리지** | **별도의 스키마가 있는 브리지** | **풀** | 
| --- | --- | --- | --- | --- | 
| 사용 사례: | 리소스 사용량을 완전히 제어하여 데이터를 격리하는 것은 핵심 요구 사항이거나 매우 크고 성능에 민감한 테넌트가 있습니다. | 데이터 격리는 주요 요구 사항이며 테넌트 데이터의 상호 참조가 제한되거나 필요하지 않습니다. | 중간 양의 데이터가 있는 중간 수의 테넌트. 테넌트의 데이터를 상호 참조해야 하는 경우이 모델이 선호됩니다. | 테넌트당 데이터가 적은 테넌트가 많습니다. | 
| 새로운 테넌트 온보딩 민첩성 | 매우 느립니다. (각 테넌트에는 새 인스턴스 또는 클러스터가 필요합니다.) | 어느 정도 느립니다. (스키마 객체를 저장하려면 각 테넌트에 대해 새 데이터베이스를 생성해야 합니다.) | 어느 정도 느립니다. (객체를 저장하려면 각 테넌트에 대해 새 스키마를 생성해야 합니다.) | 가장 빠른 옵션. (최소 설정이 필요합니다.) | 
| 데이터베이스 연결 풀 구성 작업 및 효율성 | 상당한 노력이 필요합니다. (테넌트당 하나의 연결 풀.) 효율성이 떨어집니다. (테넌트 간 데이터베이스 연결 공유가 없습니다.)  | 상당한 노력이 필요합니다. ([Amazon RDS 프록시](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html)를 사용하지 않는 한 테넌트당 하나의 연결 풀 구성.)  효율성이 떨어집니다. (테넌트 간 데이터베이스 연결 공유 없음 및 총 연결 수. 모든 테넌트의 사용량은 DB 인스턴스 클래스에 따라 제한됩니다.) | 더 적은 노력이 필요합니다. (모든 테넌트에 대해 하나의 연결 풀 구성.)  어느 정도 효율적입니다. (연결은 세션 풀 모드에서만 `SET ROLE` 또는 `SET SCHEMA` 명령을 통해 재사용됩니다. `SET` 명령은 Amazon RDS 프록시를 사용할 때 세션 고정을 발생시키지만 효율성을 위해 클라이언트 연결 풀을 제거하고 각 요청에 대해 직접 연결을 만들 수 있습니다.) | 최소한의 노력이 필요합니다. 가장 효율적입니다. (모든 테넌트에 대한 하나의 연결 풀과 모든 테넌트에서 효율적인 연결 재사용. 데이터베이스 연결 제한은 DB 인스턴스 클래스를 기반으로 합니다.) | 
| 데이터베이스 유지 관리([진공 관리](https://www.postgresql.org/docs/current/routine-vacuuming.html)) 및 리소스 사용량 | 더 간단한 관리. | 중간 정도의 복잡성. (이후 각 데이터베이스에 대해 vacuum 작업자를 시작해야 하므로 리소스 소비가 높아져 autovacuum 시작 관리자 CPU 사용량vacuum\$1naptime이 높아질 수 있습니다. 또한 각 데이터베이스에 대해 PostgreSQL 시스템 카탈로그 테이블을 정리하는 것과 관련된 추가 오버헤드가 있을 수 있습니다.) | 대규모 PostgreSQL 시스템 카탈로그 테이블. (테넌트 수 및 관계에 따라 수십 GBs 단위의 총 pg\$1catalog 크기입니다. 테이블 팽창을 제어하기 위해 vacuuming 관련 파라미터를 수정해야 할 가능성이 높습니다.) | 테이블은 테넌트 수와 테넌트당 데이터에 따라 클 수 있습니다. (테이블 팽창을 제어하기 위해 vacuuming 관련 파라미터를 수정해야 할 가능성이 높습니다.) | 
| 확장 관리 작업 | 상당한 노력(별도의 인스턴스에 있는 각 데이터베이스에 대해). | 상당한 노력(각 데이터베이스 수준에서). | 최소한의 노력(공통 데이터베이스에서 한 번). | 최소한의 노력(공통 데이터베이스에서 한 번). | 
| 배포 작업 변경 | 상당한 노력. (각 개별 인스턴스에 연결하고 변경 사항을 롤아웃합니다.) | 상당한 노력. (각 데이터베이스 및 스키마에 연결하고 변경 사항을 롤아웃합니다.) | 적당한 노력. (일반 데이터베이스에 연결하고 각 스키마에 대한 변경 사항을 롤아웃합니다.) | 최소한의 노력. (일반 데이터베이스에 연결하고 변경 사항을 롤아웃합니다.) | 
| 배포 변경 - 영향 범위 | 미니멀. (단일 테넌트가 영향을 받습니다.) | 미니멀. (단일 테넌트가 영향을 받습니다.) | 미니멀. (단일 테넌트가 영향을 받습니다.) | 매우 큽니다. (모든 테넌트가 영향을 받습니다.) | 
| 쿼리 성능 관리 및 작업 | 관리 가능한 쿼리 성능. | 관리 가능한 쿼리 성능. | 관리 가능한 쿼리 성능. | 쿼리 성능을 유지하려면 상당한 노력이 필요할 수 있습니다. (시간이 지남에 따라 테이블 크기가 증가하여 쿼리가 더 느리게 실행될 수 있습니다. 테이블 파티셔닝 및 데이터베이스 샤딩을 사용하여 성능을 유지할 수 있습니다.) | 
| 테넌트 간 리소스 영향 | 영향이 없습니다. (테넌트 간 리소스 공유 없음) | 중간 정도의 영향. (테넌트는 인스턴스 CPU 및 메모리와 같은 공통 리소스를 공유합니다.) | 중간 정도의 영향. (테넌트는 인스턴스 CPU 및 메모리와 같은 공통 리소스를 공유합니다.) | 큰 영향을 미칩니다. (테넌트는 리소스, 잠금 충돌 등의 측면에서 서로 영향을 미칩니다.) | 
| 테넌트 수준 튜닝(예: 테넌트당 추가 인덱스 생성 또는 특정 테넌트에 대한 DB 파라미터 조정) | 가능합니다. | 어느 정도 가능합니다. (각 테넌트에 대해 스키마 수준 변경을 수행할 수 있지만 데이터베이스 파라미터는 모든 테넌트에서 전역적입니다.) | 어느 정도 가능합니다. (각 테넌트에 대해 스키마 수준 변경을 수행할 수 있지만 데이터베이스 파라미터는 모든 테넌트에서 전역적입니다.) | 불가능. (테이블은 모든 테넌트가 공유합니다.) | 
| 성능에 민감한 테넌트의 작업 재조정 | 미니멀. (재분배할 필요가 없습니다. 이 시나리오를 처리하도록 서버 및 I/O 리소스를 확장합니다.) | 보통. (논리적 복제 또는 pg\$1dump를 사용하여 데이터베이스를 내보내지만 데이터 크기에 따라 가동 중지 시간이 길어질 수 있습니다. Amazon RDS for PostgreSQL의 전송 가능한 데이터베이스 기능을 사용하여 인스턴스 간에 데이터베이스를 더 빠르게 복사할 수 있습니다.) | 보통이지만 가동 중지 시간이 길어질 수 있습니다. (논리적 복제 또는 pg\$1dump를 사용하여 스키마를 내보내지만 데이터 크기에 따라 가동 중지 시간이 길어질 수 있습니다.) | 모든 테넌트가 동일한 테이블을 공유하기 때문에 중요합니다. (데이터베이스를 공유하려면 모든 것을 다른 인스턴스에 복사하고 테넌트 데이터를 정리하는 추가 단계가 필요합니다.)  대부분의 경우 애플리케이션 로직을 변경해야 합니다. | 
| 메이저 버전 업그레이드를 위한 데이터베이스 가동 중지 | 표준 가동 중지 시간. (PostgreSQL 시스템 카탈로그 크기에 따라 다름) | 가동 중지 시간이 길어질 수 있습니다. (시스템 카탈로그 크기에 따라 시간이 달라집니다. PostgreSQL 시스템 카탈로그 테이블도 데이터베이스 간에 복제됨) | 가동 중지 시간이 길어질 수 있습니다. (PostgreSQL 시스템 카탈로그 크기에 따라 시간이 달라집니다.) | 표준 가동 중지 시간. (PostgreSQL 시스템 카탈로그 크기에 따라 다름) | 
| 관리 오버헤드(예: 데이터베이스 로그 분석 또는 백업 작업 모니터링) | 상당한 노력 | 최소한의 노력. | 최소한의 노력. | 최소한의 노력. | 
| 테넌트 수준 가용성 | 가장 높음. (각 테넌트는 실패하고 독립적으로 복구됩니다.) | 더 높은 영향 범위. (하드웨어 또는 리소스 문제가 발생할 경우 모든 테넌트가 함께 실패하고 복구됩니다.) | 더 높은 영향 범위. (하드웨어 또는 리소스 문제가 발생할 경우 모든 테넌트가 함께 실패하고 복구됩니다.) | 더 높은 영향 범위. (하드웨어 또는 리소스 문제가 발생할 경우 모든 테넌트가 함께 실패하고 복구됩니다.) | 
| 테넌트 수준 백업 및 복구 작업 | 최소한의 노력. (각 테넌트는 독립적으로 백업 및 복원할 수 있습니다.) | 적당한 노력. (각 테넌트에 논리적 내보내기 및 가져오기를 사용합니다. 일부 코딩 및 자동화가 필요합니다.) | 적당한 노력. (각 테넌트에 논리적 내보내기 및 가져오기를 사용합니다. 일부 코딩 및 자동화가 필요합니다.) | 상당한 노력. (모든 테넌트는 동일한 테이블을 공유합니다.) | 
| 테넌트 수준의 point-in-time으로 복구 작업 | 최소한의 노력. (스냅샷을 사용하여 특정 시점으로 복구를 사용하거나 Amazon Aurora에서 역추적을 사용합니다.) | 적당한 노력. (스냅샷 복원을 사용한 다음 내보내기/가져오기를 사용합니다. 그러나 이는 느린 작업입니다.) | 적당한 노력. (스냅샷 복원을 사용한 다음 내보내기/가져오기를 사용합니다. 그러나 이는 느린 작업입니다.) | 상당한 노력과 복잡성. | 
| 균일한 스키마 이름 | 각 테넌트에 대해 동일한 스키마 이름입니다. | 각 테넌트에 대해 동일한 스키마 이름입니다. | 테넌트마다 스키마가 다릅니다. | 공통 스키마입니다. | 
| 테넌트별 사용자 지정(예: 특정 테넌트에 대한 추가 테이블 열) | 가능합니다. | 가능합니다. | 가능합니다. | 복잡합니다(모든 테넌트가 동일한 테이블을 공유하기 때문). | 
| 객체 관계 매핑(ORM) 계층의 카탈로그 관리 효율성(예: Ruby) | 효율적입니다(클라이언트 연결이 테넌트에 고유하기 때문). | 효율적입니다(클라이언트 연결이 데이터베이스에 고유하기 때문). | 어느 정도 효율적입니다. (사용된 ORM, 사용자/역할 보안 모델 및 search\$1path 구성에 따라 클라이언트는 경우에 따라 모든 테넌트의 메타데이터를 캐싱하여 DB 연결 메모리 사용량을 높입니다.) | 효율적입니다(모든 테넌트가 동일한 테이블을 공유하기 때문). | 
| 통합 테넌트 보고 작업 | 상당한 노력. (외부 데이터 래퍼[FDWs]를 사용하여 모든 테넌트의 데이터를 통합하거나 [ETL]을 추출, 변환 및 다른 보고 데이터베이스에 로드해야 합니다.) | 상당한 노력. (FDWs 사용하여 모든 테넌트 또는 ETL의 데이터를 다른 보고 데이터베이스로 통합해야 합니다.) | 적당한 노력. (유니온을 사용하여 모든 스키마의 데이터를 집계할 수 있습니다.) | 최소한의 노력. (모든 테넌트 데이터는 동일한 테이블에 있으므로 보고는 간단합니다.) | 
| 보고를 위한 테넌트별 읽기 전용 인스턴스(예: 구독 기반) | 최소한의 노력. (읽기 전용 복제본을 생성합니다.) | 적당한 노력. (논리적 복제 또는 AWS Database Migration Service[AWS DMS]를 사용하여 구성할 수 있습니다.) | 적당한 노력. (논리적 복제 또는를 사용하여 AWS DMS 를 구성할 수 있습니다.) | 복잡합니다(모든 테넌트가 동일한 테이블을 공유하기 때문). | 
| 데이터 격리 | 가장 좋습니다. | 더 좋습니다. (PostgreSQL 역할을 사용하여 데이터베이스 수준 권한을 관리할 수 있습니다.) | 더 좋습니다. (PostgreSQL 역할을 사용하여 스키마 수준 권한을 관리할 수 있습니다.) | 더 나쁨. (모든 테넌트가 동일한 테이블을 공유하므로 테넌트 격리를 위해 행 수준 보안[RLS]과 같은 기능을 구현해야 합니다.) | 
| 테넌트별 스토리지 암호화 키 | 가능합니다. (각 PostgreSQL 클러스터에는 스토리지 암호화를 위한 자체 AWS Key Management Service [AWS KMS] 키가 있을 수 있습니다.) | 불가능. (모든 테넌트는 스토리지 암호화를 위해 동일한 KMS 키를 공유합니다.) | 불가능. (모든 테넌트는 스토리지 암호화를 위해 동일한 KMS 키를 공유합니다.) | 불가능. (모든 테넌트는 스토리지 암호화를 위해 동일한 KMS 키를 공유합니다.) | 
| 각 테넌트의 데이터베이스 인증에 AWS Identity and Access Management (IAM) 사용 | 가능합니다. | 가능합니다. | 가능한 경우(각 스키마에 대해 별도의 PostgreSQL 사용자가 있음). | 불가능(테이블이 모든 테넌트에서 공유되기 때문). | 
| 인프라 비용 | 가장 높음(공유되는 것이 없기 때문). | 보통. | 보통. | 가장 낮음. | 
| 데이터 중복 및 스토리지 사용량 | 모든 테넌트에서 가장 높은 집계입니다. (PostgreSQL 시스템 카탈로그 테이블과 애플리케이션의 정적 및 공통 데이터는 모든 테넌트에 중복됩니다.) | 모든 테넌트에서 가장 높은 집계입니다. (PostgreSQL 시스템 카탈로그 테이블과 애플리케이션의 정적 및 공통 데이터는 모든 테넌트에 중복됩니다.) | 보통. (애플리케이션의 정적 및 공통 데이터는 공통 스키마에 있으며 다른 테넌트가 액세스할 수 있습니다.) | 미니멀. (데이터 중복 없음. 애플리케이션의 정적 데이터와 공통 데이터는 동일한 스키마에 있을 수 있습니다.) | 
| 테넌트 중심 모니터링(문제를 일으키는 테넌트를 신속하게 파악) | 최소한의 노력. (각 테넌트는 별도로 모니터링되므로 특정 테넌트의 활동을 쉽게 확인할 수 있습니다.) | 적당한 노력. (모든 테넌트는 동일한 물리적 리소스를 공유하므로 특정 테넌트의 활동을 확인하려면 추가 필터링을 적용해야 합니다.) | 적당한 노력. (모든 테넌트는 동일한 물리적 리소스를 공유하므로 특정 테넌트의 활동을 확인하려면 추가 필터링을 적용해야 합니다.) | 상당한 노력. (모든 테넌트는 테이블을 포함한 모든 리소스를 공유하므로 바인드 변수 캡처를 사용하여 특정 SQL 쿼리가 속한 테넌트를 확인해야 합니다.) | 
| 중앙 집중식 관리 및 상태/활동 모니터링 | 상당한 노력(중앙 모니터링 및 중앙 명령 센터 설정). | 적당한 노력(모든 테넌트가 동일한 인스턴스를 공유하기 때문). | 적당한 노력(모든 테넌트가 동일한 인스턴스를 공유하기 때문). | 최소한의 노력(모든 테넌트가 스키마를 포함하여 동일한 리소스를 공유하기 때문). | 
| 객체 식별자(OID) 및 트랜잭션 ID(XID) 랩어라운드의 가능성 | 미니멀. | 높음 (OID,XID는 단일 PostgreSQL 클러스터 전체 카운터이며 물리적 데이터베이스에서 효과적으로 vacuum하는 데 문제가 있을 수 있기 때문입니다). | 보통. (OID,XID는 단일 PostgreSQL 클러스터 전체 카운터이므로). | 높음 (예를 들어 단일 테이블은 out-of-line 열 수에 따라 TOAST OID 한도인 40억에 도달할 수 있습니다.) |