전용 vCPU VPS에서 PostgreSQL에 CPU와 RAM이 얼마나 필요한가요?

PostgreSQL은 vCPU를 몇 개 사용하나요?

PostgreSQL은 실행 중인 쿼리마다 CPU 스레드 하나를 사용합니다. 연결마다 자체 백엔드 프로세스가 부여되기 때문입니다. 문서는 이를 "process per user" 모델이라고 부릅니다. postmaster가 연결마다 새 백엔드를 생성합니다. 따라서 데이터베이스에 필요한 CPU는 열린 연결 수가 아니라 같은 순간에 실행되는 쿼리 수로 결정됩니다. 유휴 연결은 메모리를 차지할 뿐 CPU는 쓰지 않습니다.

쿼리 위에 스레드를 추가하는 요소는 세 가지입니다:

• Parallel query. 대규모 스캔은 도우미를 동원합니다: max_parallel_workers_per_gather의 기본값은 2, max_parallel_workers의 기본값은 8이며, max_worker_processes(기본값 8)에서 가져옵니다.
• Autovacuum. 최대 autovacuum_max_workers개의 프로세스(기본값 3)가 백그라운드에서 테이블을 정리합니다.
• 애플리케이션, 같은 VPS에서 실행되는 경우.

2 vCPU VPS에서는 병렬로 실행되는 보고서 하나가 모든 스레드를 점유해 앱의 짧은 쿼리가 뒤에서 기다릴 수 있습니다. 보고서용 롤에서 max_parallel_workers_per_gather를 낮추거나 플랜을 올리면 해결됩니다. 이 수치의 근거가 되는 스레드 대 코어 규칙은 전용 vCPU는 코어인가 스레드인가에서 설명합니다.

PostgreSQL은 VPS에서 RAM을 얼마나 필요로 할까요?

shared_buffers는 VPS RAM의 25%로 시작하고, 나머지 대부분은 운영체제의 페이지 캐시에 남겨 두세요. PostgreSQL 18 문서는 RAM이 1 GB 이상인 전용 데이터베이스 서버에 이 시작 값을 제시하며, PostgreSQL이 커널 캐시에도 의존하기 때문에 40%를 넘기면 더 나아지기 어렵다고 덧붙입니다. 기본 제공 값은 128 MB입니다.

RAM에서 따라오는 설정이 두 가지 더 있습니다:

• effective_cache_size는 플래너를 위한 추정치일 뿐입니다(기본값 4 GB). shared_buffers와 페이지 캐시가 합쳐서 담는 크기로 설정해 인덱스 스캔 비용이 올바르게 계산되도록 하세요.
• work_mem(기본값 4 MB)은 각 세션의 정렬 또는 해시 단계마다 적용됩니다. 복잡한 쿼리 하나가 이를 여러 번 사용하고, 많은 세션이 동시에 그렇게 하므로 신중하게 늘려야 합니다.

2026년 11월 2일 Cobaltfell의 조사에 따르면, 신분 확인 없이 암호화폐를 받는 호스트에서 기록된 전용 CPU 플랜 202개 중 106개가 vCPU당 4 GB 이상의 RAM을 제공했습니다. 데이터베이스에서는 vCPU 수만큼 vCPU당 RAM도 중요합니다.

이 집계의 근거가 된 플랜은 2026년 11월 전용 CPU VPS의 코어당 비용에 나열되어 있습니다.

CPU steal은 PostgreSQL p99 레이턴시에 어떤 영향을 주나요?

CPU steal은 평균을 움직이기 훨씬 전에 가장 느린 1%의 쿼리를 늘립니다. Linux 커널은 steal을 비자발적 대기로 설명합니다. vCPU에 작업이 있는데 하이퍼바이저가 다른 이의 작업을 실행한 시간입니다. 쿼리 도중 멈춘 백엔드는 그대로 멈추고, 그 쿼리나 그 쿼리가 보유한 락을 기다리는 모든 클라이언트도 함께 멈춥니다.

멈춤은 짧고 불규칙해서 그 순간 마침 CPU에 있던 쿼리만 맞습니다. 측정값이 아닌 예시로: vCPU가 이웃 때문에 때때로 수십 밀리초를 잃으면, 그 구간에 걸린 2 ms 쿼리는 열 배 더 오래 걸리는 반면 그 주변의 수천 개 쿼리는 정상 속도로 실행됩니다. 평균은 거의 변하지 않고 99번째 백분위수가 비용 전체를 떠안습니다.

따라서 공유 vCPU의 데이터베이스는 평균에서는 건강해 보여도 타임아웃을 계속 만들어 냅니다. 세 가지 지표가 이를 드러냅니다:

• Steal: 가장 바쁜 시간대의 mpstat 중 %steal 열이며, CPU steal 시간이란 무엇이고 VPS에서 어떻게 확인하는지에서 설명합니다.
• 최악의 경우: pg_stat_statements는 구문별로 max_exec_time와 stddev_exec_time를 보고하며, 백분위수는 없습니다.
• 백분위수: log_min_duration_statement(예: 250ms)이 느린 구문을 기록하며, 애플리케이션의 레이턴시 히스토그램이 p99 자체를 제공합니다.

# queries on the CPU right now (run at your busiest hour)
psql -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';"

# statements with the worst single run (needs pg_stat_statements in shared_preload_libraries)
psql -c "SELECT left(query, 60) AS query, calls,
  round(mean_exec_time::numeric, 2) AS mean_ms,
  round(max_exec_time::numeric, 2) AS max_ms
  FROM pg_stat_statements ORDER BY max_exec_time DESC LIMIT 10;"

# steal per vCPU, every 5 seconds (package sysstat)
mpstat -P ALL 5 6

전용 vCPU는 데이터베이스에 어떤 변화를 주나요?

전용 vCPU는 VPS 내부에서는 조정할 수 없는 테일 레이턴시의 한 가지 원인을 제거합니다. 느린 플랜, 빠진 인덱스, 락 경합은 운영자가 고칠 일이지만, 공유 코어에서 이웃의 배치 작업이 도는 것은 아닙니다. 일반적인 내용은 공유 vCPU와 전용 vCPU의 차이는 무엇인가에 정리되어 있습니다. Cobaltfell VPS에서는:

• CPU: vCPU 하나는 호스트 프로세서의 하드웨어 스레드 하나입니다. 고객님의 vCPU는 VPS에 1대1로 고정되며 다른 고객에게 절대 빌려주지 않고, 물리 코어의 두 스레드는 함께 유지되므로 2 vCPU마다 이웃이 공유하지 않는 온전한 코어 하나가 됩니다.
• Steal: 전용 vCPU에서는 steal time이 0 또는 0에 가까워야 합니다. 자체 장비에서 측정한 수치를 날짜와 함께 공개하며, 추정치는 절대 내지 않습니다.
• 메모리: 플랜의 RAM은 고객님의 VPS를 위해 확보되며 초과 할당되지 않습니다.
• 디스크: 모든 플랜에 NVMe 스토리지.
• 부하: 작업에 필요한 만큼 얼마든지 풀 부하를 허용합니다. CPU 크레딧도, 버스트 시간도, 100%에서 몇 분이 지난 뒤의 스로틀링도 없습니다. 긴 VACUUM나 인덱스 빌드는 최대 속도로 실행됩니다.

프로세서 계열은 AMD EPYC 9004/9005(Zen 4 / Zen 5)입니다.

PostgreSQL에 VPS가 맞지 않는 경우는 언제인가요?

매분 조회하는 데이터가 가장 큰 플랜의 RAM보다 훨씬 클 때, 또는 레플리카와 백업을 대신 관리받아야 할 때 VPS는 맞지 않습니다. Fell 16은 32 GB입니다. 메모리에 들어가지 않는 작업 세트는 모든 쿼리를 디스크 읽기로 바꾸며, 그때는 vCPU가 아니라 스토리지 처리량이 속도를 정합니다.

백업은 운영자 몫으로 남습니다: 백업은 어떤 플랜에도 포함되지 않습니다. 데이터 사본을 다른 곳에 보관하세요. 야간 pg_dump나 다른 곳의 스토리지로 보내는 WAL 아카이브가 대부분의 소규모 데이터베이스를 커버하며, 복원 테스트는 필요해지기 전에 일정에 넣어 두어야 합니다.

두세 대의 VPS 간 스트리밍 복제를 통한 장애 조치는 가능하지만 직접 관리해야 합니다. Cobaltfell은 서버를 판매하며 관리형 데이터베이스는 판매하지 않습니다. 각 크기의 가격은 전용 코어 VPS의 비용은 얼마인가에 나열되어 있습니다.