매니지드 PostgreSQL – 퍼블릭 베타
Postgres,군더더기 없이본질만.
$ capydb create
postgres://user:pass@myapp.db.capydb.dev:5432/main
이 프로젝트에 쓸 CapyDB Postgres 데이터베이스를 준비해 줘. https://capydb.dev/agents.md 를 받아서 네 환경에 맞는 안내를 따라가면 돼. 내가 필요한 건 딱 한 번, 브라우저 탭에서 접근을 승인할 때야. 나머지는 전부 맡길게.
Claude Code, Cursor, Copilot 등에서 동작합니다. 브라우저에서 한 번만 승인하면 계정, 데이터베이스, 환경 변수까지 정리됩니다.
/a
격리된 셀
남의 Postgres를 나눠 쓰는 게 아닙니다.
/b
진짜 Postgres
Postgres를 말할 줄 알면 그대로 동작합니다.
/c
쓰고 버리는 프리뷰
머지했으면 그대로 삭제.
/d
시간 되감기
최근 30일 중 어느 1초로든 되돌립니다.
01기본 단위
프로젝트 하나에 셀 하나.
데이터베이스는 서비스의 단위입니다. CapyDB에서는 그것을 셀이라 부릅니다. 전용 프로세스, 스토리지, 자격 증명, 확장 기능, CPU/메모리 상한을 가진 독립적인 Postgres입니다. 셀은 저희가 운영하고, 여러분은 평범한 Postgres URL을 쓰면 됩니다.
사양표
단위 하나를, 제대로.
데이터베이스 셀
프로젝트마다 격리된 Postgres가 따로 돌아갑니다. 전용 프로세스, 스토리지, 자격 증명, 확장 기능, CPU/메모리 상한까지. 몇 초면 준비됩니다.
프로세스 · 스토리지 · 자격 증명 · cpu/메모리
쓰고 버리는 프리뷰
풀 리퀘스트마다 프로덕션을 새 셀로 복제합니다. 브랜치와 함께 만료되고, TTL이 뒷정리를 해 줍니다.
즉시 복제 · 자동 만료
SDK 말고, 연결 문자열
표준 postgres:// URL을 직접 또는 풀러를 거쳐 사용합니다. Postgres를 말할 줄 알면 그대로 동작합니다. 쓰던 ORM도, CLI도, 15년 된 GUI 클라이언트도.
sdk 없음 · 방언 없음 · 종속 없음
격리, 항목별로
프로세스, 자격 증명, 스토리지 할당량, 네트워크, CPU, 메모리까지 셀 단위로 분리됩니다. TLS는 항상 필수이고, 자격 증명 교체는 명령 하나면 됩니다.
전 구간 tls · 즉시 교체
특정 시점 복원
트랜잭션 로그를 계속 아카이브합니다. 최근 30일 중 어느 1초든 새 셀로 복원할 수 있습니다. 테이블을 날리는 날은 언젠가 오니까요.
pitr · 30일 구간
02프리뷰 데이터베이스
PR마다 전용 셀 하나.
프리뷰 데이터베이스는 브랜치와 함께 생겼다가 브랜치와 함께 사라집니다. 자기 셀에서, 자기 연결 문자열로 돌아가고, 프로덕션은 건드리지 않습니다.
03스케일 투 제로
쉴 땐 잠들고, 연결하면 깨어납니다.
쉬고 있는 셀은 연산 자원을 반납하고 스토리지는 그대로 둡니다. 연결하면 돌아옵니다. 보통 1초가 걸리지 않습니다. 연결 문자열은 바뀌지 않습니다.
번거로움 없이.
명령어 셋이면 바로 배포
생성
프로젝트 하나, 셀 하나. 몇 초면 됩니다.
capydb create연결
쓰던 도구가 그대로 동작합니다.
DATABASE_URL=postgres://…배포
PR마다 프리뷰. 머지되면 삭제.
git push && npm run deploy04리전
노드 위의 셀. 노드가 이루는 그리드.
정하실 건 리전 하나뿐입니다. 여러분의 셀은 저희가 직접 소유하고 현지에서 운영하는 하드웨어에 배치됩니다. 그리드의 모든 노드는 똑같이 심심한 구성으로 돌아갑니다.
05만들지 않은 것
저희가 만들지 않은 것들.
인증 애드온 없습니다. 스토리지 버킷 없습니다. 함수 실행 환경 없습니다. 밑단을 새로 쓴 스토리지 엔진도 없습니다. 표준 Postgres를 아주 잘 운영하는 것, 엔지니어링 시간은 전부 거기 들어갔습니다.
06격리의 실제 범위
격리됩니다. 과장 없이.
공용 Postgres 서버가 아닙니다. 프로젝트마다 격리된 Postgres가 따로 주어지고, 프로세스·자격 증명·스토리지 할당량·네트워크·CPU·메모리가 각각 분리됩니다. 표준 요금제에서 딱 하나 공유되는 것이 있습니다. 스토리지 I/O는 최선 노력 방식입니다.
솔직한 적합성 점검
도구는 골라 쓰는 것.
이럴 때 잘 맞습니다
- 백엔드 플랫폼이 아니라 매니지드 Postgres가 필요할 때.
- 독자 SDK보다 연결 문자열이 편할 때.
- PR마다 데이터베이스를 복제할 때.
- 쓰던 도구를 그대로 계속 쓰고 싶을 때.
이럴 땐 다른 선택지를
- 인증, 스토리지, 함수까지 한 묶음으로 필요할 때.
- GraphQL/REST API 자동 생성이 필요할 때.
- 특정 벤더에 묶여도 괜찮을 때.
- SQL은 되도록 쓰고 싶지 않을 때.
플랫폼이 필요하면 플랫폼을 사세요. Postgres를 온전히 쓰고 싶다면, 저희가 있습니다.