Relyt One 소개: 코드처럼 브랜치하는 서버리스 Postgres
Relyt One은 쓰기 시 복사(copy-on-write) 브랜치, 유휴 상태일 때 일시 중지되는 컴퓨트, 기본 제공 벡터 검색, 관리형 인증을 갖춘 서버리스 PostgreSQL 17입니다. 작동 방식과 함께, 로그인부터 브랜치된 데이터베이스까지 5분 만에 가는 방법을 소개합니다.
이 페이지의 내용
Relyt One은 개발자와 AI 에이전트를 위한 서버리스 Postgres입니다. 표준 PostgreSQL 17에 더해, 풀 리퀘스트와 미리 보기, 에이전트 실행마다 쓸 수 있는 데이터베이스 브랜치, 아무도 사용하지 않을 때는 일시 중지되는 컴퓨트, 그리고 대부분의 앱이 결국 덧붙이게 되는 구성 요소(연결 풀링, 벡터 검색, Open API, 관리형 인증)를 제공합니다. 무료로 시작할 수 있고 신용카드도 필요 없으며, GitHub 또는 Google로 로그인하면 몇 분 뒤에 데이터베이스를 쓸 수 있습니다.
이 글에서는 Relyt One이 무엇인지, 왜 이런 방식으로 만들어졌는지, 그리고 실제로 사용하면 어떤 모습인지를 첫 연결 문자열부터 프로덕션 데이터가 담긴 일회용 브랜치까지 차례로 설명합니다.
Postgres는 새 애플리케이션의 기본 데이터베이스이며, 그럴 만한 이유가 있습니다. 반면 Postgres를 운영하는 방식은 크게 달라지지 않았습니다. 관리형 Postgres 인스턴스는 본질적으로 여전히 한 대의 머신입니다. 정해진 양의 CPU와 메모리에 디스크가 붙어 있고, 누가 접속하든 말든 계속 실행됩니다.
이 모델에는 어느 팀에서든 언젠가는 드러나는 세 가지 비용이 있습니다.
환경이 비싸서 수가 부족합니다. 누구나 프로덕션과 똑같은 스테이징 데이터베이스, 풀 리퀘스트마다 하나씩 있는 데이터베이스, 마이그레이션이 안전하게 실패해도 되는 샌드박스를 원합니다. 하지만 머신 형태의 Postgres에서는 그 하나하나가 프로비저닝할 인스턴스이고, 복원할 덤프이고, 또 하나의 청구서입니다. 그래서 팀은 스테이징 데이터베이스 하나를 함께 쓰고, 시드 데이터 몇 행으로 마이그레이션을 테스트하고, 느린 ALTER TABLE을 프로덕션에서야 알게 됩니다.
유휴 데이터베이스도 바쁜 데이터베이스와 같은 비용이 듭니다. 사이드 프로젝트, 사내 도구, 미리 보기 환경, 데모 앱은 대부분의 시간을 아무것도 하지 않으며 보냅니다. 항상 켜져 있는 머신은 그 '아무것도 하지 않는' 시간 전부에 요금을 부과합니다.
에이전트는 두 문제를 모두 악화시킵니다. 작업마다 데이터베이스를 만들고, 스키마 변경을 시도하고, 테스트를 실행한 뒤 결과를 버릴 수 있는 코딩 에이전트는 개발 데이터베이스를 함께 써야 하는 에이전트보다 훨씬 유용합니다. 하지만 이는 데이터베이스를 git 브랜치만큼 저렴하고 빠르게 만들 수 있을 때만 가능합니다.
Relyt One은 이 세 가지 문제를 모두 없애기 위해 다른 아키텍처에서 출발합니다.
핵심 아이디어는 컴퓨트와 스토리지의 분리입니다.
스토리지는 데이터의 기록을 보관하는 공유 계층입니다. 컴퓨트는 하나의 브랜치에 대한 쿼리를 처리하고 스토리지에서 페이지를 읽어 오는 일반 Postgres 17 프로세스입니다. 데이터가 컴퓨트의 디스크에 있지 않기 때문에, 예전에는 비쌌던 세 가지가 저렴해집니다.
브랜치는 특정 시점의 상위 브랜치에서 시작하는 새로운 기록 흐름입니다. 브랜치를 만들어도 데이터는 복사되지 않습니다. 새 브랜치는 둘 중 한쪽이 변경하기 전까지 상위 브랜치와 모든 페이지를 공유하며, 변경된 페이지만 새 공간을 차지합니다. 그래서 상위 브랜치에 1메가바이트가 있든 100기가바이트가 있든 브랜치를 만드는 비용은 같고, 콘솔은 전체 사본 대신 각 브랜치의 상위 브랜치 대비 스토리지 증가분을 보여 줄 수 있습니다. 새 브랜치의 컴퓨트를 프로비저닝하는 데는 잠시 시간이 걸리지만, 데이터는 브랜치가 생기는 즉시 그곳에 있습니다.
브랜치는 트리를 이룹니다. main에서 브랜치를 만들고, 그 브랜치에서 다시 브랜치를 만들 수 있습니다. 브랜치를 삭제해도 상위 브랜치나 형제 브랜치에는 아무 영향이 없습니다. 하위 브랜치가 남아 있는 브랜치는 하위 브랜치가 모두 없어질 때까지 삭제할 수 없습니다. 기본 브랜치는 삭제할 수 없으므로 main은 항상 존재합니다.
과거 시점에서 브랜치를 만들 수도 있습니다. 프로젝트가 기록을 보존하고 있으면(프로젝트의 기록 보존 설정에서 지정하며 최대 최근 3시간), 새 브랜치는 '지금' 대신 그 기간 안의 어느 시점의 상위 브랜치 데이터에서든 시작할 수 있습니다. 잘못된 마이그레이션을 배포한 아침에 유용합니다. 배포 10분 전 시점에서 브랜치를 만들어 행이 어떤 모습이었는지 확인하고, 필요한 데이터를 다시 복사해 오면 됩니다.
각 브랜치는 컴퓨트 유닛(1 CU = 1 vCPU + 4 GB RAM) 단위로 크기가 정해지는 자체 컴퓨트에서 처리됩니다. 미리 보기 브랜치에서 무거운 테스트를 실행해도 프로덕션과 CPU를 두고 경쟁하지 않으며, 에이전트의 실험이 사용자가 읽고 있는 테이블을 잠글 수도 없습니다.
컴퓨트에 한동안(기본값은 약 10분) 할 일이 없으면 일시 중지됩니다. 상태가 ACTIVE에서 SUSPENDED로 바뀌고 CPU를 사용하지 않습니다. 데이터는 처음부터 컴퓨트에 있지 않았으므로 그대로입니다. 다음 연결이 들어오면 컴퓨트가 재개됩니다. 하루에 몇 분만 바쁜 수많은 데이터베이스에게 이는 머신에 비용을 내느냐, 작업에 비용을 내느냐의 차이입니다.
- 유사품이 아닌 PostgreSQL 17. 사용 중인 드라이버, ORM,
psql, pgAdmin, DBeaver가 그대로 작동합니다.pg_trgm,citext,pgcrypto같은 확장은CREATE EXTENSION으로 사용할 수 있습니다. - 현재 데이터 또는 최근 몇 시간의 데이터에서 만드는 브랜치. 브랜치마다 자체 컴퓨트를 가지며, 콘솔이나 API로 만들 수 있습니다.
- PgBouncer의 트랜잭션 수준 풀링을 통한 연결 풀링으로 최대 10,000개의 동시 연결을 지원합니다. 서버리스 함수와 그 밖의 수명이 짧은 연결에는 풀링 연결 문자열을 사용하세요.
- 기본 제공 벡터 검색.
vectors확장(pgvector가 아닌 pgvecto.rs)이 미리 로드되어 있고 기본적으로 데이터베이스에 생성되므로, 임베딩을 설명 대상 행 바로 옆에 둘 수 있습니다. - 모든 컴퓨트의 관측성: CPU, 메모리, 연결, 데이터베이스 크기 차트, 실시간 활성 쿼리, 호출 수와 소요 시간을 포함한 쿼리 기록.
- 조직, 프로젝트, 브랜치, 컴퓨트를 다루는, API 키 기반의 Open API.
- 관리형 인증(미리 보기). 앱 사용자를 위한 로그인 기능을 브랜치에 연결해 제공하며, 사용자는 해당 브랜치의 데이터베이스에 저장됩니다. 자세한 내용은 Relyt One 관리형 인증, 미리 보기 공개를 참고하세요.
전체 흐름은 다음과 같습니다. 프로젝트를 만들고, 연결하고, 브랜치를 만들고, 브랜치에서 스키마를 변경한 뒤, 브랜치를 버립니다.
GitHub 또는 Google로 로그인하세요. 처음 로그인하면 무료 조직이 자동으로 만들어집니다.
프로젝트를 만드세요. 이름을 정하고, 리전을 선택하고, PostgreSQL 비밀번호를 설정합니다. 프로젝트는 기본 브랜치 main, 기본 컴퓨트, 데이터베이스 relytdb와 그 소유자 역할 relytdb_owner를 갖춘 상태로 시작합니다. 컴퓨트를 프로비저닝하는 데 몇 분이 걸릴 수 있으며, 준비가 끝나면 브랜치 페이지에 표시됩니다.
브랜치를 열고 Connect(연결)를 선택하세요. 컴퓨트, 데이터베이스, 역할을 고르고 연결 문자열을 복사합니다. 이 대화 상자에는 Prisma와 Java용 기성 코드 조각, GUI 클라이언트용 호스트와 포트 정보, 풀링 연결 문자열도 있습니다.
export DATABASE_URL="postgresql://<역할>:<비밀번호>@<호스트>/<데이터베이스>?sslmode=require"
psql "$DATABASE_URL" -c "select version();"브랜치할 대상이 생기도록 테이블과 몇 개의 행을 만드세요.
CREATE TABLE customers (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
email text NOT NULL UNIQUE,
created_at timestamptz NOT NULL DEFAULT now()
);
INSERT INTO customers (email)
SELECT 'user' || g || '@example.com' FROM generate_series(1, 100000) AS g;Branches(브랜치) 페이지에서 New Branch(새 브랜치)를 선택하고, 상위 브랜치로 main을 선택한 뒤 Current data(현재 데이터)를 그대로 둡니다. 이름은 add-plan-column으로 정합니다.
이 브랜치에는 처음부터 100,000개의 행이 모두 있고, 자체 컴퓨트와 자체 연결 문자열도 있습니다. 컴퓨트가 준비되었다고 표시되면 연결하세요. 아무것도 복사되지 않았으므로 상위 브랜치 대비 스토리지 증가분은 0에서 시작합니다.
같은 작업을 Open API로 하면 다음과 같습니다. CI 작업이나 에이전트가 사용하는 방식입니다($PROJECT_ID는 프로젝트의 obj-… ID이고, parentBranchSlug는 상위 브랜치의 br-… 슬러그입니다).
curl https://relyt.one/api/v1/projects/$PROJECT_ID/branches \
-H "x-api-key: $RELYT_API_KEY" \
-H "content-type: application/json" \
-d '{"name": "add-plan-column", "parentBranchSlug": "br-..."}'대신 "pointInTime": "2026-10-30T08:50:00Z"를 추가하면 그 시점의 상위 브랜치에서 브랜치를 만듭니다. 이 시각은 프로젝트의 기록 보존 기간 안에 있어야 합니다.
브랜치에 연결하고, 확신이 서지 않는 마이그레이션을 실행하세요.
ALTER TABLE customers ADD COLUMN plan text NOT NULL DEFAULT 'free';
CREATE INDEX customers_plan_idx ON customers (plan);실제 데이터에서 얼마나 걸리는지, 이후 쿼리 계획이 어떻게 바뀌는지, 애플리케이션이 여전히 작동하는지를 main에 전혀 손대지 않고 알 수 있습니다. Monitoring(모니터링)을 열고 브랜치의 컴퓨트를 선택하면 CPU 급증을 볼 수 있고, Query History(쿼리 기록)에서 실행된 문을 확인할 수 있습니다.
결과가 만족스러운가요? 평소의 배포 절차로 main에서 같은 마이그레이션을 실행하세요. 만족스럽지 않다면 브랜치를 삭제하세요. 어느 쪽이든 실험에 든 비용은 몇 초간의 컴퓨트와 변경된 페이지뿐입니다.
프로젝트와 브랜치를 만들고 삭제하는 일은 API 호출 한 번이면 되므로, Relyt One은 작업마다 실제 데이터베이스가 필요한 코딩 에이전트에 잘 맞습니다.
- Open API로 프로젝트와 브랜치를 만들고 삭제하고(각 브랜치에는 자체 컴퓨트가 함께 제공됩니다), 컴퓨트 상태와 메트릭을 조회하고, API 키를 관리할 수 있습니다. 모든 엔드포인트는 API 레퍼런스에 나와 있습니다.
- 오픈 소스 **에이전트 스킬 팩**은 Claude Code와 그 밖의 에이전트에게 프로비저닝, 브랜치, 연결 방법을 알려 주므로 에이전트가 추측할 필요가 없습니다.
- 작업마다 브랜치. 에이전트에게 전용 브랜치를 주고 그곳에서 마이그레이션과 테스트를 실행하게 한 다음, 무엇이든
main에 반영되기 전에 diff를 검토하세요.
모든 계정은 Free(무료) 요금제로 시작합니다.
| Free | |
|---|---|
| 조직 | 1 |
| 프로젝트 | 5 |
| 스토리지 | 2.5 GB(프로젝트당 0.5 GB 포함) |
| 컴퓨트 | 공유 컴퓨트 시간 무제한(얼리버드 혜택) |
신용카드도, 체험 기간 제한도 없습니다.
데이터베이스는 Postgres이고, 그 주변 도구는 공개되어 있습니다. 관리형 인증 토큰을 검증하는 @relyt/auth, 예제 앱, 에이전트 스킬이 모두 MIT 라이선스로 GitHub에 있습니다.
로그인하고, 프로젝트를 만들고, 브랜치를 만들어 보세요. 헷갈리거나 작동하지 않는 부분이 있으면 꼭 알려 주세요. 콘솔의 피드백 버튼을 사용하면 됩니다.
태그Postgresserverlessbranching



