Mythex 앱마다 데이터베이스를 따로 주는 이유
Mythex에서 만든 앱이 데이터(회원가입, 예약, 주문)를 저장해야 하면, Mythex는 그 프로젝트에 자체 Postgres 데이터베이스를 제공합니다. 공유 데이터베이스 안의 테이블도, 다른 누군가의 스키마 옆의 스키마도 아닙니다. 요청 시 만들어지는 별도의 데이터베이스이며, 아무도 사용하지 않으면 잠듭니다. 우리가 이렇게 만든 이유와 그 비용을 설명합니다.
무엇을 얻나요
데이터를 요청하면(“대기자 이메일 저장해 줘”, “예약 저장해 줘”) 또는 /database 명령을 사용하면, Mythex는 다음을 합니다.
- 프로젝트 전용 Postgres 데이터베이스를 만듭니다(현재 Postgres 17).
- 연결 정보를 작업 공간과 게시된 앱에 환경 변수로 주입하므로, 코드에는 절대 나타나지 않습니다.
- 에이전트가 테이블을 만들고 데이터를 읽고 쓸 수 있게 합니다.
라이브 미리보기와 게시된 앱은 같은 데이터베이스를 사용합니다. 데이터베이스는 5분 유휴 후 잠들고, 다음 쿼리에 깨어납니다. 새 데이터베이스는 작게 시작하며 부하에 따라 확장할 수 있고, 폭주하는 쿼리가 끝없이 커지지 않도록 상한이 있습니다. 자세한 내용은 데이터베이스 문서에서 볼 수 있습니다.
하나의 큰 공유 데이터베이스를 쓰지 않는 이유
행마다 어떤 앱에 속하는지 적은 열이 있는 공유 데이터베이스는 운영하기에 더 저렴하고 단순합니다. 그래도 우리가 그렇게 하지 않은 이유는 네 가지입니다.
1. 믿을 필요가 없는 격리
AI가 작성한 코드는 실수를 합니다. 공유 데이터베이스에서는 한 앱의 쿼리에서 WHERE app_id = … 하나만 빠져도 다른 고객의 데이터를 읽거나 덮어쓸 수 있습니다. 앱마다 데이터베이스를 따로 두면, 도달할 수 있는 다른 고객의 데이터가 없습니다. 버그는 자신의 앱 안에 머뭅니다.
2. 독점 계층이 아니라 진짜 Postgres
여러분의 앱은 일반적인 연결 문자열로 표준 Postgres와 통신합니다. Postgres와 작동하는 라이브러리, ORM, 도구는 무엇이든 여기서 작동합니다. 다른 곳에서 실행하려고 프로젝트를 내보내면, 그 프로젝트는 Mythex 전용 API가 아니라 Postgres 데이터베이스를 기대하며, 이는 모든 호스팅 제공자가 제공하는 것입니다.
3. 각 앱을 필요한 모양으로 만들 수 있습니다
한 앱은 시간 슬롯에 고유 제약이 있는 bookings 테이블을 원하고, 다른 앱은 상품에 대한 전문 검색을 원합니다. 각 앱이 자체 데이터베이스를 가지면, 각 앱의 스키마와 마이그레이션은 그 앱만의 일입니다. 최소 공통분모 설계에 맞출 필요가 없습니다.
4. 비용이 사용량을 따라갑니다
각 데이터베이스는 독립적으로 잠들기 때문에, 아무도 사용하지 않는 앱은 거의 비용이 들지 않고, 바쁜 앱의 비용은 자신의 항목으로 분명하게 보입니다. 게시된 데이터베이스 사용량은 데이터베이스가 실제로 측정한 값을 기준으로 청구됩니다. 이 청구 방식을 참고하세요.
트레이드오프
이 설계가 공짜는 아닙니다.
- 콜드 스타트. 잠든 데이터베이스는 조용한 시간 뒤 첫 쿼리에서 깨어나는 데 잠깐 걸립니다. 대부분의 앱에서는 거의 눈에 띄지 않습니다. 언제든 즉시 응답해야 하는 앱에는 고려할 사항입니다.
- 깨어 있는 동안의 비용. 무언가 데이터베이스를 조회하는 동안은 데이터베이스가 깨어 있습니다. 몇 초마다 데이터베이스를 폴링하는 앱은 하루 종일 깨어 있으므로, 필요할 때 조회하는 앱보다 비용이 더 듭니다. 사용량이 예상보다 높아 보인다면 대개 이 때문입니다. 폴링을 멈추고 필요할 때 데이터를 불러오도록 AI에 요청하세요.
- 우리 쪽의 움직이는 부품이 더 많습니다. 수천 개의 데이터베이스를 만들고, 추적하고, 정리하는 일은 하나를 관리하는 것보다 많은 작업입니다. 그것은 여러분이 아니라 우리가 감당할 문제입니다.
데이터베이스가 처음이라면
데이터베이스는 앱이 기억해야 하는 것을 보관하는 곳입니다. 개념이 낯설다면 데이터베이스란 무엇인가와 Postgres란 무엇인가부터 시작하세요. 데이터를 저장하는 무언가를 만들 준비가 되면, AI로 앱을 만드는 방법이 데이터베이스를 추가하는 과정을 안내합니다.