PlanetScale + Vercel: DATABASE_URL과 DIRECT_URL을 나눠야 하는 이유
접속 문자열을 정리한다며 시크릿 이름 하나를 통일했습니다. 그날 밤 운영 사이트 로그인이 죽었고, 백업은 아무 소리 없이 깨졌습니다.
접속 문자열을 정리한다며 시크릿 이름 하나를 통일했습니다. 그날 밤 운영 사이트 로그인이 죽었고, 백업은 아무 소리 없이 깨졌습니다.
로컬에 둔 영업 DB 가 원본보다 뒤처져 있었습니다. 리드가 254건인데 원본은 282건이었습니다. 활동 기록은 171건 대 281건으로 더 벌어져 있었습니다.
운영 데이터베이스를 Supabase에서 PlanetScale Postgres로 옮겼습니다. 옮기고 나서 사이트가 조금 굼떠진 것 같았습니다. 클라우드를 건너뛰게 됐으니 그 대가겠거니 생각했는데, 재보니 아니었습니다. 원인은 이관과 상관없이 원래 있던 커넥션 풀 설정이었고, 그것도 제 첫 측정으로는 보이지 않았습니다.
테이블에서 100만 행을 지웠습니다. DELETE는 성공했고 SELECT count()는 0을 돌려줍니다.
Neon과 Supabase를 대신할 서비스를 정리해 달라는 질문을 받았습니다. 처음에는 후보를 한 표에 놓고 유명한 순서부터 매기려 했습니다. 공식 문서를 다시 읽어 보니 출발점부터 잘못되었습니다.
Supabase와 Neon을 처음 보면 둘 다 관리형 PostgreSQL 서비스처럼 보입니다. 실제로 두 서비스 모두 표준 PostgreSQL 연결 방식과 SQL 생태계를 활용합니다. 그래서 기능표만 훑으면 가격과 무료 용량 정도만 비교하게 됩니다.
운영 중인 서비스의 데이터베이스를 온프레미스에서 Supabase로 옮기는 중입니다. 지난번에 1단계로 앱을 무상태화했고, 이번이 2단계인 스키마 복제입니다. 프로젝트를 만들고 접속 문자열을 받아 prisma migrate deploy 한 줄 돌리면 끝나는 일이라고 생각했습니다. 그 전에 빈 데이터베이스에 한 번 리허설을…
PostgreSQL을 처음 접하면 MySQL과 비슷한 관계형 데이터베이스라고 생각하기 쉽습니다.
사내 시스템을 새로 만들 때 인프라를 처음부터 크게 잡아야 할지 고민하게 됩니다. 특히 Supabase Pro를 검토하면 Micro와 Small의 월 비용 차이는 크지 않지만, 어떤 기준으로 선택해야 하는지는 가격표만 보고 판단하기 어렵습니다.