سرور ابری برای PostgreSQL — راهنمای انتخاب و بهینه‌سازی

بهترین سرور برای اجرای PostgreSQL چه ویژگی‌هایی باید داشته باشد؟ راهنمای انتخاب منابع، تنظیمات performance، بک‌آپ، replication و امنیت دیتابیس.

نویسنده

تیم فنی زیر ساخت افرادین

دسته‌بندی

PostgreSQL

زمان مطالعه

01 Min read

تاریخ انتشار

25 Jul, 2026

سرور ابری برای PostgreSQL — راهنمای انتخاب و بهینه‌سازی

PostgreSQL قدرتمندترین دیتابیس متن‌باز جهان است—از استارتاپ‌های کوچک گرفته تا بانک‌ها و سازمان‌های دولتی. اما PostgreSQL عاشق RAM است، به CPU سریع نیاز دارد و بدون NVMe SSD، حتی قوی‌ترین کوئری‌ها هم کند اجرا می‌شوند. اگر قرار است PostgreSQL قلب اپلیکیشن شما باشد، سرور باید به همان اندازه جدی گرفته شود.

PostgreSQL روی چه سروری اجرا شود؟

پاسخ کوتاه: VPS با حداقل ۴ گیگ RAM و NVMe SSD. اما PostgreSQL مثل یک ماشین مسابقه‌ای است—با بنزین معمولی (SSD کند) هم کار می‌کند، ولی قدرت واقعی‌اش را فقط با سوخت مناسب (NVMe + RAM کافی) نشان می‌دهد.

برخلاف MySQL که می‌تواند با منابع محدود هم کار کند، PostgreSQL از همان ابتدا برای performance طراحی شده و اگر منابع کافی در اختیارش نگذارید، به جای کمک، دردسر می‌شود.

چه CPU و RAM برای PostgreSQL لازم است؟

حجم دیتابیسCPURAMفضای ذخیره‌سازی
کمتر از ۱ گیگ۱-۲ هسته۲-۴ گیگ۲۰ گیگ NVMe
۱-۱۰ گیگ۲-۴ هسته۴-۸ گیگ۴۰-۶۰ گیگ NVMe
۱۰-۵۰ گیگ۴-۶ هسته۸-۱۶ گیگ۸۰-۱۲۰ گیگ NVMe
۵۰-۲۰۰ گیگ۶-۸ هسته۱۶-۳۲ گیگ۲۰۰-۴۰۰ گیگ NVMe
بیش از ۲۰۰ گیگ۸-۱۶ هسته۳۲-۶۴ گیگ۵۰۰+ گیگ NVMe

قانون RAM برای PostgreSQL: shared_buffers (کش اصلی) باید حدود ۲۵٪ از RAM باشد. اگر ۸ گیگ RAM دارید، shared_buffers = 2GB. بقیه RAM برای کش فایل‌سیستم (page cache) استفاده می‌شود که PostgreSQL برای خواندن از دیسک به آن وابسته است.

قانون CPU: PostgreSQL می‌تواند از چندین هسته برای parallel query استفاده کند—مخصوصاً برای sequential scanها، aggregate functionها و index creation. هرچه هسته بیشتر، parallel query سریع‌تر.

NVMe SSD — حیاتی، نه اختیاری

PostgreSQL با WAL (Write-Ahead Log) کار می‌کند—قبل از اینکه داده در دیتابیس ذخیره شود، ابتدا در WAL نوشته می‌شود. این یعنی هر عملیات write دو بار روی دیسک انجام می‌شود—یک بار در WAL، یک بار در data files.

اگر از SSD معمولی استفاده کنید، WAL به یک bottleneck جدی تبدیل می‌شود. NVMe با IOPS بسیار بالاتر، WAL را بدون ایجاد تأخیر مدیریت می‌کند.

نکته حرفه‌ای: اگر بودجه دارید، WAL را روی یک دیسک NVMe جداگانه قرار دهید. این کار performance نوشتن را تا ۴۰٪ بهبود می‌دهد.

تنظیمات کلیدی PostgreSQL

فایل postgresql.conf را بر اساس منابع VPS خود تنظیم کنید:

# Memory
shared_buffers = 2GB            # 25% of RAM
effective_cache_size = 6GB      # 75% of RAM
work_mem = 64MB                 # Per-operation memory
maintenance_work_mem = 512MB    # For VACUUM, CREATE INDEX

# WAL
wal_buffers = 64MB
wal_level = replica             # Required for replication
max_wal_size = 4GB
min_wal_size = 1GB

# Query Planning
random_page_cost = 1.1          # Lower for NVMe (default 4.0 is for HDD!)
effective_io_concurrency = 200  # Higher for NVMe

# Connections
max_connections = 100

مهم‌ترین تغییر: random_page_cost را حتماً روی ۱.۱ تنظیم کنید (برای NVMe). مقدار پیش‌فرض ۴.۰ برای هارد دیسک‌های قدیمی طراحی شده و باعث می‌شود PostgreSQL به اشتباه sequential scan را به index scan ترجیح دهد.

Connection Pooling با PgBouncer

PostgreSQL برای هر connection یک process جداگانه ایجاد می‌کند. اگر اپلیکیشن شما ۱۰۰ connection هم‌زمان باز کند، ۱۰۰ process PostgreSQL خواهید داشت—هر کدام RAM مصرف می‌کنند.

راه حل: PgBouncer—یک connection pooler سبک که connectionهای زیادی را با multiplexing به چند connection واقعی PostgreSQL تبدیل می‌کند. مصرف RAM آن ناچیز است (چند مگابایت) اما تأثیرش روی performance چشمگیر.

بک‌آپ — هرگز فراموش نکنید

سه روش برای بک‌آپ PostgreSQL:

۱. pg_dump: بک‌آپ منطقی—خروجی SQL. برای دیتابیس‌های کوچک تا ۱۰ گیگ مناسب است ۲. pg_basebackup: بک‌آپ فیزیکی کامل—سریع‌تر از pg_dump برای دیتابیس‌های بزرگ ۳. WAL Archiving + PITR: حرفه‌ای‌ترین روش—امکان restore تا یک لحظه خاص (Point-in-Time Recovery)

برای اکثر پروژه‌ها، ترکیب pg_dump روزانه + WAL archiving کافی است.

# Cron job for daily backup at 3 AM
0 3 * * * pg_dump -U postgres mydb | gzip > /backups/mydb_$(date +\%Y\%m\%d).sql.gz

Replication — برای high availability

اگر downtime برای شما غیرقابل قبول است، replication را تنظیم کنید:

  • Streaming Replication: یک سرور primary، یک یا چند replica—همیشه یک کپی به‌روز از دیتابیس دارید
  • Synchronous vs Asynchronous: synchronous یعنی صفر از دست رفتن داده (ولی کمی کندتر)، asynchronous یعنی performance بالاتر (ولی ریسک چند ثانیه data loss)

برای یک VPS، streaming replication با یک replica کافی است. VPS دوم را در دیتاسنتر دیگری انتخاب کنید تا در برابر disaster هم محافظت شوید.

امنیت PostgreSQL

  • هرگز PostgreSQL را روی 0.0.0.0 بایند نکنید—فقط localhost یا IPهای مشخص
  • از pg_hba.conf برای محدود کردن دسترسی استفاده کنید—فقط کاربران و دیتابیس‌های ضروری را مجاز کنید
  • SSL for connections: ssl = on در postgresql.conf
  • پسورد قوی: حداقل ۲۰ کاراکتر، ترکیبی از حروف، اعداد و نمادها

جمع‌بندی: سرور مناسب PostgreSQL شما

برای یک دیتابیس PostgreSQL تولیدی با ۱۰-۵۰ گیگ داده:

  • CPU: ۴-۶ هسته
  • RAM: ۱۲-۱۶ گیگابایت
  • ذخیره‌سازی: ۸۰-۱۲۰ گیگابایت NVMe SSD
  • سیستم‌عامل: Ubuntu 22.04 LTS
  • Connection Pooler: PgBouncer
  • بک‌آپ: pg_dump روزانه + WAL Archiving
  • Replication: Streaming replication (اختیاری—برای high availability)

👈 سرور مناسب PostgreSQL خود را انتخاب کنید


مقالات مرتبط