Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Model partisi SaaS multi-penyewa untuk PostgreSQL Metode terbaik untuk mencapai multi-tenancy tergantung pada persyaratan untuk aplikasi SaaS Anda. Bagian berikut menunjukkan model partisi untuk berhasil menerapkan multi-tenancy di PostgreSQL. **catatan** Model yang dibahas di bagian ini berlaku untuk Amazon RDS for PostgreSQL dan Aurora PostgreSQL yang kompatibel. Referensi ke *PostgreSQL* di bagian ini berlaku untuk kedua layanan. Ada tiga model tingkat tinggi yang dapat Anda gunakan di PostgreSQL untuk partisi SaaS: silo, jembatan, dan kolam. Gambar berikut merangkum trade-off antara model silo dan kolam renang. Model jembatan adalah hibrida dari model silo dan kolam renang. **** | **Model partisi** | **Keuntungan** | **Kekurangan** | | --- | --- | --- | | Silo | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | | Kolam | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | | Jembatan | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | Bagian berikut membahas setiap model secara lebih rinci. **Topics** + [ # Model silo PostgreSQL ](silo.md) + [ # Model kolam PostgreSQL ](pool.md) + [ # Model jembatan PostgreSQL ](bridge.md) + [ # Matriks keputusan ](matrix.md) # Model silo PostgreSQL Model silo diimplementasikan dengan menyediakan instance PostgreSQL untuk setiap penyewa dalam aplikasi. *Model silo unggul dalam kinerja penyewa dan isolasi keamanan, dan sepenuhnya menghilangkan fenomena tetangga yang bising.* Fenomena tetangga yang bising terjadi ketika satu penyewa menggunakan sistem mempengaruhi kinerja penyewa lain. Model silo memungkinkan Anda menyesuaikan kinerja secara khusus untuk setiap penyewa dan berpotensi membatasi pemadaman pada silo penyewa tertentu. Namun, apa yang umumnya mendorong adopsi model silo adalah batasan keamanan dan peraturan yang ketat. Kendala ini dapat dimotivasi oleh pelanggan SaaS. Misalnya, pelanggan SaaS mungkin menuntut agar data mereka diisolasi karena kendala internal, dan penyedia SaaS mungkin menawarkan layanan seperti itu dengan biaya tambahan. ![\[SaaS PostgreSQL silo model\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-silo.png) Meskipun model silo mungkin diperlukan dalam kasus-kasus tertentu, ia memiliki banyak kelemahan. Seringkali sulit untuk menggunakan model silo dengan cara yang hemat biaya, karena mengelola konsumsi sumber daya di beberapa instance PostgreSQL dapat menjadi rumit. Selain itu, sifat terdistribusi beban kerja database dalam model ini membuatnya lebih sulit untuk mempertahankan pandangan terpusat dari aktivitas penyewa. Mengelola begitu banyak beban kerja yang dioperasikan secara independen meningkatkan overhead operasional dan administratif. Model silo juga membuat orientasi penyewa lebih rumit dan memakan waktu, karena Anda harus menyediakan sumber daya khusus penyewa. Selain itu, seluruh sistem SaaS bisa lebih sulit untuk diskalakan, karena jumlah instans PostgreSQL khusus penyewa yang terus meningkat akan menuntut lebih banyak waktu operasional untuk dikelola. Satu pertimbangan terakhir adalah bahwa aplikasi atau lapisan akses data harus mempertahankan pemetaan penyewa ke instance PostgreSQL terkait mereka, yang menambah kompleksitas penerapan model ini. # Model kolam PostgreSQL [Model pool diimplementasikan dengan menyediakan satu instance PostgreSQL (Amazon RDS atau Aurora) dan menggunakan keamanan tingkat baris (RLS) untuk mempertahankan isolasi data penyewa.](https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/) Kebijakan RLS membatasi baris mana dalam tabel yang dikembalikan oleh `SELECT` kueri atau baris mana yang terpengaruh oleh`INSERT`,`UPDATE`, dan perintah. `DELETE` Model pool memusatkan semua data penyewa dalam satu skema PostgreSQL, sehingga secara signifikan lebih hemat biaya dan membutuhkan lebih sedikit overhead operasional untuk mempertahankannya. Pemantauan solusi ini juga jauh lebih sederhana karena sentralisasinya. Namun, pemantauan dampak spesifik penyewa dalam model kumpulan biasanya memerlukan beberapa instrumentasi tambahan dalam aplikasi. Ini karena PostgreSQL secara default tidak mengetahui penyewa mana yang mengkonsumsi sumber daya. Orientasi penyewa disederhanakan karena tidak diperlukan infrastruktur baru. Kelincahan ini membuatnya lebih mudah untuk mencapai alur kerja orientasi penyewa yang cepat dan otomatis. ![\[SaaS PostgreSQL pool model\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-pool.png) Meskipun model kolam umumnya lebih hemat biaya dan lebih mudah dikelola, model ini memiliki beberapa kelemahan. Fenomena tetangga yang bising tidak dapat sepenuhnya dihilangkan dalam model kolam renang. Namun, hal ini dapat dikurangi dengan memastikan bahwa sumber daya yang sesuai tersedia pada instance PostgreSQL dan dengan menggunakan strategi untuk mengurangi beban di PostgreSQL, seperti membongkar kueri untuk membaca replika atau ke Amazon. ElastiCache Pemantauan yang efektif juga berperan dalam menanggapi masalah isolasi kinerja penyewa, karena instrumentasi aplikasi dapat mencatat dan memantau aktivitas khusus penyewa. Terakhir, beberapa pelanggan SaaS mungkin tidak menemukan pemisahan logis yang disediakan oleh RLS cukup dan mungkin meminta tindakan isolasi tambahan. # Model jembatan PostgreSQL Model jembatan PostgreSQL adalah kombinasi dari pendekatan gabungan dan silo. Seperti model gabungan, Anda menyediakan satu instance PostgreSQL untuk setiap penyewa. Untuk mempertahankan isolasi data penyewa, Anda menggunakan konstruksi logis PostgreSQL. Dalam diagram berikut, database PostgreSQL digunakan untuk memisahkan data secara logis. **catatan** Database PostgreSQL tidak merujuk ke Amazon RDS terpisah untuk instans DB yang kompatibel dengan Amazon RDS for PostgreSQL atau Aurora PostgreSQL. Sebaliknya, ini mengacu pada konstruksi logis dari sistem manajemen database PostgreSQL untuk memisahkan data. ![\[SaaS PostgreSQL bridge model with separate databases\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-dbs.png) Anda juga dapat mengimplementasikan model jembatan dengan menggunakan database PostgreSQL tunggal, dengan skema khusus penyewa di setiap database, seperti yang diilustrasikan dalam diagram berikut. ![\[SaaS PostgreSQL bridge model with separate schemas\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-schemas.png) Model jembatan menderita masalah isolasi kinerja tetangga yang bising dan penyewa yang sama dengan model kolam renang. Ini juga menimbulkan beberapa overhead operasional dan penyediaan tambahan dengan mengharuskan database atau skema terpisah untuk disediakan berdasarkan per-penyewa. Diperlukan pemantauan yang efektif untuk merespons dengan cepat masalah kinerja penyewa. Ini juga membutuhkan instrumentasi aplikasi untuk memantau penggunaan khusus penyewa. Secara keseluruhan, model bridge dapat dilihat sebagai alternatif dari RLS yang sedikit menambah upaya orientasi penyewa dengan membutuhkan database atau skema PostgreSQL baru. Seperti halnya model silo, aplikasi atau lapisan akses data harus mempertahankan pemetaan penyewa ke database atau skema PostgreSQL terkait. # Matriks keputusan Untuk memutuskan model partisi SaaS multi-tenant mana yang harus Anda gunakan dengan PostgreSQL, lihat matriks keputusan berikut. Matriks menganalisis empat opsi partisi ini: + Silo — Sebuah instance PostgreSQL terpisah atau cluster untuk setiap penyewa. + Bridge dengan database terpisah — Database terpisah untuk setiap penyewa dalam satu instance PostgreSQL atau cluster. + Jembatan dengan skema terpisah - Skema terpisah untuk setiap penyewa dalam database PostgreSQL tunggal, dalam satu instance PostgreSQL atau cluster. + Pool — Tabel bersama untuk penyewa dalam satu contoh dan skema. **** | **** | **Silo** | **Jembatan dengan database terpisah** | **Jembatan dengan skema terpisah** | **Kolam** | | --- | --- | --- | --- | --- | | Kasus penggunaan | Isolasi data dengan kontrol penuh penggunaan sumber daya adalah persyaratan utama, atau Anda memiliki penyewa yang sangat besar dan sangat sensitif terhadap kinerja. | Isolasi data adalah persyaratan utama, dan referensi silang data penyewa terbatas atau tidak diperlukan. | Jumlah penyewa moderat dengan jumlah data moderat. Ini adalah model yang disukai jika Anda harus referensi silang data penyewa. | Sejumlah besar penyewa dengan lebih sedikit data per penyewa. | | Kelincahan orientasi penyewa baru | Sangat lambat. (Sebuah instance atau cluster baru diperlukan untuk setiap penyewa.) | Cukup lambat. (Membutuhkan pembuatan database baru untuk setiap penyewa untuk menyimpan objek skema.) | Cukup lambat. (Membutuhkan pembuatan skema baru untuk setiap penyewa untuk menyimpan objek.) | Opsi tercepat. (Diperlukan pengaturan minimal.) | | Upaya dan efisiensi konfigurasi kumpulan koneksi basis data | Diperlukan upaya yang signifikan. (Satu kolam koneksi per penyewa.) Kurang efisien. (Tidak ada berbagi koneksi database antara penyewa.) | Diperlukan upaya yang signifikan. (Satu konfigurasi kumpulan koneksi per penyewa kecuali Anda menggunakan [Amazon RDS Proxy.](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html)) Kurang efisien. (Tidak ada berbagi koneksi database antara penyewa dan jumlah total koneksi. Penggunaan di semua penyewa terbatas berdasarkan kelas instans DB.) | Lebih sedikit usaha yang dibutuhkan. (Satu konfigurasi kumpulan koneksi untuk semua penyewa.) Cukup efisien. (Koneksi digunakan kembali melalui `SET SCHEMA` perintah `SET ROLE` or dalam mode kumpulan sesi saja. `SET`perintah juga menyebabkan penyematan sesi saat menggunakan Amazon RDS Proxy, tetapi kumpulan koneksi klien dapat dihilangkan dan koneksi langsung dapat dibuat untuk setiap permintaan efisiensi.) | Usaha paling sedikit yang dibutuhkan. Paling efisien. (Satu kumpulan koneksi untuk semua penyewa dan penggunaan kembali koneksi yang efisien di semua penyewa. Batas koneksi database didasarkan pada kelas instans DB.) | | Pemeliharaan basis data ([manajemen vakum](https://www.postgresql.org/docs/current/routine-vacuuming.html)) dan penggunaan sumber daya | Manajemen yang lebih sederhana. | Kompleksitas sedang. (Mungkin menyebabkan konsumsi sumber daya yang tinggi, karena pekerja vakum harus dimulai untuk setiap database setelahnyavacuum\$1naptime, yang mengarah ke penggunaan CPU peluncur autovacuum yang tinggi. Mungkin juga ada overhead tambahan yang terkait dengan menyedot debu tabel katalog sistem PostgreSQL untuk setiap database.) | Tabel katalog sistem PostgreSQL besar. (pg\$1catalogUkuran total dalam puluhan GBs, tergantung pada jumlah penyewa dan hubungan. Kemungkinan memerlukan modifikasi pada parameter terkait penyedotan debu untuk mengontrol kembung tabel.) | Tabel mungkin besar, tergantung pada jumlah penyewa dan data per penyewa. (Kemungkinan memerlukan modifikasi pada parameter terkait penyedotan debu untuk mengontrol kembung tabel.) | | Upaya manajemen ekstensi | Upaya yang signifikan (untuk setiap database dalam contoh terpisah). | Upaya yang signifikan (di setiap tingkat database). | Upaya minimal (satu kali dalam database umum). | Upaya minimal (satu kali dalam database umum). | | Ubah upaya penerapan | Upaya yang signifikan. (Connect ke setiap instance terpisah dan luncurkan perubahan.) | Upaya yang signifikan. (Connect ke setiap database dan skema, dan luncurkan perubahan.) | Upaya moderat. (Connect ke database umum dan luncurkan perubahan untuk setiap skema.) | Usaha minimal. (Connect ke database umum dan luncurkan perubahan.) | | Ubah penyebaran — ruang lingkup dampak | Minimal. (Penyewa tunggal terpengaruh.) | Minimal. (Penyewa tunggal terpengaruh.) | Minimal. (Penyewa tunggal terpengaruh.) | Sangat besar. (Semua penyewa terpengaruh.) | | Manajemen dan upaya kinerja kueri | Kinerja kueri yang dapat dikelola. | Kinerja kueri yang dapat dikelola. | Kinerja kueri yang dapat dikelola. | Upaya signifikan mungkin diperlukan untuk mempertahankan kinerja kueri. (Seiring waktu, kueri mungkin berjalan lebih lambat karena peningkatan ukuran tabel. Anda dapat menggunakan partisi tabel dan sharding database untuk mempertahankan kinerja.) | | Dampak sumber daya lintas penyewa | Tidak ada dampak. (Tidak ada pembagian sumber daya di antara penyewa.) | Dampak sedang. (Penyewa berbagi sumber daya umum seperti CPU dan memori instance.) | Dampak sedang. (Penyewa berbagi sumber daya umum seperti CPU dan memori instance.) | Dampak berat. (Penyewa saling mempengaruhi dalam hal sumber daya, konflik kunci, dan sebagainya.) | | Penyetelan tingkat penyewa (misalnya, pembuatan indeks tambahan per penyewa atau penyesuaian parameter DB untuk penyewa tertentu) | Mungkin. | Agak mungkin. (Perubahan tingkat skema dapat dilakukan untuk setiap penyewa, tetapi parameter database bersifat global di semua penyewa.) | Agak mungkin. (Perubahan tingkat skema dapat dilakukan untuk setiap penyewa, tetapi parameter database bersifat global di semua penyewa.) | Tidak mungkin. (Tabel dibagikan oleh semua penyewa.) | | Upaya menyeimbangkan kembali untuk penyewa yang peka terhadap kinerja | Minimal. (Tidak perlu menyeimbangkan kembali. Skala server dan I/O sumber daya untuk menangani skenario ini.) | Sedang. (Gunakan replikasi logis atau pg\$1dump untuk mengekspor database, tetapi waktu henti mungkin panjang tergantung pada ukuran data. Anda dapat menggunakan fitur database yang dapat diangkut di Amazon RDS for PostgreSQL untuk menyalin database antar instance dengan lebih cepat.) | Sedang tetapi kemungkinan melibatkan waktu henti yang lama. (Gunakan replikasi logis atau pg\$1dump untuk mengekspor skema, tetapi waktu henti mungkin panjang tergantung pada ukuran data.) | Signifikan, karena semua penyewa berbagi tabel yang sama. (Sharding database membutuhkan penyalinan semuanya ke instance lain dan langkah tambahan untuk membersihkan data penyewa.) Kemungkinan besar membutuhkan perubahan logika aplikasi. | | Waktu henti basis data untuk peningkatan versi utama | Waktu henti standar. (Tergantung pada ukuran katalog sistem PostgreSQL.) | Kemungkinan downtime yang lebih lama. (Tergantung pada ukuran katalog sistem, waktunya akan bervariasi. Tabel katalog sistem PostgreSQL juga diduplikasi di seluruh database) | Kemungkinan downtime yang lebih lama. (Tergantung pada ukuran katalog sistem PostgreSQL, waktunya akan bervariasi.) | Waktu henti standar. (Tergantung pada ukuran katalog sistem PostgreSQL.) | | Administrasi overhead (misalnya, untuk analisis log database atau pemantauan pekerjaan cadangan) | Upaya yang signifikan | Usaha minimal. | Usaha minimal. | Usaha minimal. | | Ketersediaan tingkat penyewa | Tertinggi. (Setiap penyewa gagal dan pulih secara mandiri.) | Lingkup dampak yang lebih tinggi. (Semua penyewa gagal dan pulih bersama jika terjadi masalah perangkat keras atau sumber daya.) | Lingkup dampak yang lebih tinggi. (Semua penyewa gagal dan pulih bersama jika terjadi masalah perangkat keras atau sumber daya.) | Lingkup dampak yang lebih tinggi. (Semua penyewa gagal dan pulih bersama jika terjadi masalah perangkat keras atau sumber daya.) | | Upaya pencadangan dan pemulihan tingkat penyewa | Usaha paling sedikit. (Setiap penyewa dapat didukung dan dipulihkan secara independen.) | Upaya moderat. (Gunakan ekspor dan impor logis untuk setiap penyewa. Beberapa pengkodean dan otomatisasi diperlukan.) | Upaya moderat. (Gunakan ekspor dan impor logis untuk setiap penyewa. Beberapa pengkodean dan otomatisasi diperlukan.) | Upaya yang signifikan. (Semua penyewa berbagi tabel yang sama.) | | Upaya pemulihan tingkat penyewa point-in-time | Usaha minimal. (Gunakan pemulihan waktu point-in dengan menggunakan snapshot, atau gunakan backtracking di Amazon Aurora.) | Upaya moderat. (Gunakan pemulihan snapshot, diikuti oleh ekspor/impor. Namun, ini akan menjadi operasi yang lambat.) | Upaya moderat. (Gunakan pemulihan snapshot, diikuti oleh ekspor/impor. Namun, ini akan menjadi operasi yang lambat.) | Upaya dan kompleksitas yang signifikan. | | Nama skema seragam | Nama skema yang sama untuk setiap penyewa. | Nama skema yang sama untuk setiap penyewa. | Skema yang berbeda untuk setiap penyewa. | Skema umum. | | Kustomisasi per penyewa (misalnya, kolom tabel tambahan untuk penyewa tertentu) | Mungkin. | Mungkin. | Mungkin. | Rumit (karena semua penyewa berbagi tabel yang sama). | | Efisiensi manajemen katalog pada lapisan pemetaan relasional objek (ORM) (misalnya, Ruby) | Efisien (karena koneksi klien khusus untuk penyewa). | Efisien (karena koneksi klien khusus untuk database). | Cukup efisien. (Tergantung pada ORM yang digunakan, model user/role keamanan, dan search\$1path konfigurasi, klien terkadang menyimpan metadata untuk semua penyewa, yang mengarah ke penggunaan memori koneksi DB yang tinggi.) | Efisien (karena semua penyewa berbagi tabel yang sama). | | Upaya pelaporan penyewa konsolidasi | Upaya yang signifikan. (Anda harus menggunakan pembungkus data asing [FDWs] untuk mengkonsolidasikan data di semua penyewa atau mengekstrak, mengubah, dan memuat [ETL] ke database pelaporan lain.) | Upaya yang signifikan. (Anda harus menggunakan FDWs untuk mengkonsolidasikan data di semua penyewa atau ETL ke database pelaporan lain.) | Upaya moderat. (Anda dapat mengumpulkan data di semua skema dengan menggunakan serikat pekerja.) | Usaha minimal. (Semua data penyewa ada dalam tabel yang sama, jadi pelaporannya sederhana.) | | Instance read-only khusus penyewa untuk pelaporan (misalnya, berdasarkan langganan) | Usaha paling sedikit. (Buat replika baca.) | Upaya moderat. (Anda dapat menggunakan replikasi logis atau AWS Database Migration Service [AWS DMS] untuk mengonfigurasi.) | Upaya moderat. (Anda dapat menggunakan replikasi logis atau AWS DMS untuk mengkonfigurasi.) | Rumit (karena semua penyewa berbagi tabel yang sama). | | Isolasi data | Terbaik. | Lebih baik. (Anda dapat mengelola izin tingkat database dengan menggunakan peran PostgreSQL.) | Lebih baik. (Anda dapat mengelola izin tingkat skema dengan menggunakan peran PostgreSQL.) | Lebih buruk. (Karena semua penyewa berbagi tabel yang sama, Anda harus menerapkan fitur seperti keamanan tingkat baris [RLS] untuk isolasi penyewa.) | | Kunci enkripsi penyimpanan khusus penyewa | Mungkin. (Setiap cluster PostgreSQL dapat memiliki kunci AWS KMS[] AWS Key Management Service sendiri untuk enkripsi penyimpanan.) | Tidak mungkin. (Semua penyewa berbagi kunci KMS yang sama untuk enkripsi penyimpanan.) | Tidak mungkin. (Semua penyewa berbagi kunci KMS yang sama untuk enkripsi penyimpanan.) | Tidak mungkin. (Semua penyewa berbagi kunci KMS yang sama untuk enkripsi penyimpanan.) | | Menggunakan AWS Identity and Access Management (IAM) untuk otentikasi database untuk setiap penyewa | Mungkin. | Mungkin. | Kemungkinan (dengan memiliki pengguna PostgreSQL terpisah untuk setiap skema). | Tidak mungkin (karena tabel dibagikan oleh semua penyewa). | | Biaya infrastruktur | Tertinggi (karena tidak ada yang dibagikan). | Sedang. | Sedang. | Terendah. | | Duplikasi data dan penggunaan penyimpanan | Agregat tertinggi di semua penyewa. (Tabel katalog sistem PostgreSQL dan data statis dan umum aplikasi digandakan di semua penyewa.) | Agregat tertinggi di semua penyewa. (Tabel katalog sistem PostgreSQL dan data statis dan umum aplikasi digandakan di semua penyewa.) | Sedang. (Data statis dan umum aplikasi dapat berada dalam skema umum dan diakses oleh penyewa lain.) | Minimal. (Tidak ada duplikasi data. Data statis dan umum aplikasi dapat berada dalam skema yang sama.) | | Pemantauan penyewa-sentris (dengan cepat mencari tahu penyewa mana yang menyebabkan masalah) | Usaha paling sedikit. (Karena setiap penyewa dipantau secara terpisah, mudah untuk memeriksa aktivitas penyewa tertentu.) | Upaya moderat. (Karena semua penyewa berbagi sumber daya fisik yang sama, Anda harus menerapkan penyaringan tambahan untuk memeriksa aktivitas penyewa tertentu.) | Upaya moderat. (Karena semua penyewa berbagi sumber daya fisik yang sama, Anda harus menerapkan penyaringan tambahan untuk memeriksa aktivitas penyewa tertentu.) | Upaya yang signifikan. (Karena semua penyewa berbagi semua sumber daya, termasuk tabel, Anda harus menggunakan tangkapan variabel bind untuk memeriksa penyewa mana kueri SQL tertentu milik.) | | Manajemen dan health/activity pemantauan terpusat | Upaya yang signifikan (untuk mengatur pemantauan pusat dan pusat komando pusat). | Upaya moderat (karena semua penyewa berbagi contoh yang sama). | Upaya moderat (karena semua penyewa berbagi contoh yang sama). | Upaya minimal (karena semua penyewa berbagi sumber daya yang sama, termasuk skema). | | Peluang pengenal objek (OID) dan ID transaksi (XID) sampul | Minimal. | Tinggi. (Karena OID, XID adalah penghitung cluster PostgreSQL tunggal dan mungkin ada masalah penyedot debu secara efektif di seluruh database fisik). | Sedang. (Karena OID, XID adalah penghitung cluster PostgreSQL tunggal). | Tinggi. (Misalnya, satu tabel dapat mencapai batas TOAST OID sebesar 4 miliar, tergantung pada jumlah out-of-line kolom.) |