자체 호스팅 데이터베이스에 RAM이 얼마나 필요한가요?

한 앱에는 — Postgres나 Redis 인스턴스와 그 백엔드 — 1.7-2 GB가 현실적인 워킹 셋이라 Small($8)이 맞습니다. 여러 앱, 또는 실제 동시성을 가진 프로덕션 데이터베이스는 Medium($12)으로, 다른 기기가 닿아야 하면 전용 IP 요금제로 밉니다. 희망이 아니라 워킹 셋과 연결 수로 크기를 잡으세요.

관리형 데이터베이스 대신 자체 호스팅하는 이유는?

통제입니다. postgresql.conf 전체, 슈퍼유저, 원하는 어떤 확장이든 얻습니다 — pgvector, PostGIS, TimescaleDB, pg_cron — 관리형 등급이 흔히 잠그거나 추가 요금을 매기는 것들. 트레이드오프는 백업, 튜닝, 업그레이드가 당신 일이라는 것. 박스를 소유하고 싶다면, 그것이 요점입니다.

공유 VPS가 프로덕션 데이터베이스에 괜찮은가요?

소~중 규모 앱에는, 네. 무거운 OLTP — 초당 수백 트랜잭션, 지연에 민감한 쓰기 — 에는 공유 vCPU 박스가 잘못된 도구이고, 팔기보다 그렇게 말합니다. 디스크 I/O와 보장된 클록이 거기서 중요하고, 공유 요금제는 둘 다 약속하지 않습니다.

다른 서버를 데이터베이스에 연결하게 하려면?

Postgres를 올바른 인터페이스에 바인딩하고, 포트를 필요한 IP에만 열고, 주소가 안정적이고 닿을 수 있도록 전용 IPv4 요금제를 쓰세요. 5432를 인터넷 전체에 절대 노출하지 마세요 — 앱 서버로 방화벽하고 TLS를 요구하세요.

신분증을 드려야 하나요?

아니요. 가입은 이메일, 결제는 USDC나 USDT. 서류 없음, 약 1분 만에 root.

데이터베이스용 VPS

완전한 root의 VPS에서 PostgreSQL이나 Redis를 자체 호스팅하세요 — postgresql.conf 전체, 관리형 서비스가 설치하게 두지 않는 확장, 그리고 공유 박스가 받을 수 있는 것과 없는 것에 대한 솔직한 한계. 월 $8부터.

관리형 데이터베이스가 편리하길 멈추고 벽이 되기 시작하는 특정한 순간이 있습니다. 등급이 제공하지 않는 확장을 원합니다. 실제 쿼리 계획을 보고 work_mem을 튜닝하고 싶습니다. 슈퍼유저를 원합니다. 관리형 서비스는 그것을 소유해야 할 때까지는 훌륭한 기본값입니다 — 그리고 그때, 완전한 root의 VPS가 솔직한 답입니다.

이 페이지는 자신의 PostgreSQL이나 Redis를 제대로 돌리는 것, 그리고 공유 박스가 어디서 옳은 판단이고 어디서 아닌지를 분명히 하는 것에 관한 것입니다.

데이터베이스가 실제로 필요로 하는 것

데이터베이스는 게임 서버가 신경 쓰지 않는 두 가지를 신경 씁니다: 워킹 셋을 위한 메모리와 디스크 I/O. 대략적 모습:

한 앱 — Postgres(나 Redis) 인스턴스와 백엔드 서비스. 워킹 셋은 대개 1.7-2 GB. Small($8)이 소란 없이 처리합니다.
몇 앱, 또는 진짜 프로덕션 동시성 — 더 많은 연결, 더 큰 캐시, 백그라운드 작업. Medium($12)이 여유를 줍니다.
다른 기기가 닿아야 함 — 안정적이고 라우팅 가능한 주소를 원하니, 전용 IPv4 요금제(Small-IP $16 이상). 아래에서 자세히.

Redis는 더 가볍습니다 — 메모리 바운드라, 요금제를 데이터셋에 오버헤드를 더해 크기 잡으면 끝. Postgres가 약간의 튜닝에 보답하는 것입니다.

자체 호스팅의 진짜 이유: 통제

여기서 VPS가 제자리를 법니다. 자신의 박스에서 이것을 얻습니다:

postgresql.conf 전체 — shared_buffers, work_mem, max_connections, WAL 설정, 그 전부를, 벤더의 기본값이 아니라 당신의 워크로드에 맞춰 튜닝.
어떤 확장이든. 임베딩과 의미 검색의 pgvector, 지리공간의 PostGIS, 시계열의 TimescaleDB, pg_cron, pg_stat_statements — 필요한 것을 설치. 관리형 등급은 흔히 확장 목록을 제한하거나 더 높은 요금제 뒤에 둡니다.
슈퍼유저와 그 아래 OS. 데이터 디렉터리를 옮기고, 커널을 튜닝하고, 자신의 스케줄로 pg_dump를 돌리고, 원하면 다른 박스로 스트리밍 복제를 설정할 수 있습니다.

그 어느 것도 당신에게 중요하지 않다면, 관리형 데이터베이스가 정말 괜찮고 그것을 써야 합니다. 이 페이지는 중요한 경우를 위한 것입니다.

공유 박스가 잘못된 도구인 곳

솔직하게: 공유 vCPU VPS는 무거운 OLTP — 초당 수백 트랜잭션에 지연에 민감한 쓰기 — 를 위해 만들어지지 않았습니다. 그 워크로드는 보장된 디스크 I/O와 꾸준한 클록으로 살고 죽고, 공유 요금제는 둘 다 약속하지 않습니다. 그게 당신이라면 전용 하드웨어를 원하고, 당신의 p99 지연이 우리 둘을 무안하게 하는 걸 보기보다 지금 말하겠습니다.

훨씬 흔한 경우 — 한 앱 뒤의 데이터베이스, 내부 도구, 분석 스토어, 캐시 — 에는 공유 요금제가 딱 옳습니다.

백업은 선택이 아니다

자체 호스팅은 백업이 당신 일이라는 것이고, 유일한 규칙은: 필요해지기 전에 하라. Postgres에는 논리 백업에 cron으로 pg_dump, 정말 중요한 것에는 시점 복구를 위한 WAL 아카이빙. 덤프를 박스 밖으로 보내세요 — 오브젝트 스토리지나 다른 서버로 — 죽은 디스크가 백업을 데려가지 않게. 적어도 한 번 복원을 테스트하세요. 복원해 본 적 없는 백업은 희망이지 백업이 아닙니다.

다른 서버를 연결하게 하기

데이터베이스가 같은 박스의 앱에만 서빙한다면, localhost에 바인딩하면 끝 — 노출할 게 없습니다. 다른 기기가 들어와야 하는 순간, 두 가지가 바뀝니다:

안정적이고 라우팅 가능한 주소가 필요 — 그것이 전용 IPv4 요금제(Small-IP $16, Medium-IP $20). NAT 요금제는 주소를 공유하고, 아웃바운드에는 괜찮지만 다른 서버가 다이얼인하는 데이터베이스가 되기에는 아닙니다.
강하게 방화벽합니다. 5432(나 6379)를 필요한 특정 IP에만 열고, 0.0.0.0/0에는 절대 열지 않고, TLS를 요구합니다. 공개 인터넷의 열린 Postgres 포트는 몇 분 안에 발견됩니다.

요금제 고르기

설정	요금제
한 앱 뒤의 DB, localhost만	Small($8)
몇 앱 / 프로덕션 동시성	Medium($12)
다른 서버가 접속해 와야 함	Small-IP($16) / Medium-IP($20)
무거운 OLTP, 수백 TPS	전용 하드웨어, 공유 VPS가 아니라

대부분의 자체 호스팅 데이터베이스는 Small에서 시작해 더 많은 앱이나 외부 클라이언트를 떠맡으면서 Medium이나 전용 IP 요금제로 자랍니다.

왜 여기인가

완전한 root는 그것이 당신의 데이터베이스라는 뜻, 맨 아래까지 — 모든 설정 줄, 모든 확장, 자신의 백업 스케줄, 설치할 수 있는 것을 정하는 등급 없이. 결제는 암호화폐(Base, Ethereum, Polygon의 USDC나 USDT), KYC 없음, 서류 없음. 결제 약 60초 뒤 root, 몇 분 뒤 Postgres가 연결을 받게 할 수 있습니다.

솔직한 요약: 통제를 원할 때 — 확장, 튜닝, 슈퍼유저 — 그리고 워크로드가 중간일 때 자체 호스팅하세요. 소~중 규모 앱의 데이터베이스에는 공유 요금제가 알맞은 도구. 지연에 민감한 OLTP의 수백 TPS에는 아니고, 그렇게 말합니다. 준비됐나요? 요금제를 고르세요.