Firestore 가격 계산: read 비용 추정과 절감

월간 활성 사용자 수만 보지 말고 반복되는 화면부터 계산하세요. 화면당 문서 수에 세션당 조회 수, 사용자당 세션 수, 월간 활성 사용자 수를 곱합니다. write, delete, 저장 데이터, 네트워크 전송량은 별도 입력으로 더합니다.

게시글 20개를 읽은 뒤 작성자, 댓글, 카운터를 따로 가져오는 피드는 화면 조회 수보다 훨씬 많은 read를 만들 수 있습니다. 일부 쿼리는 읽은 인덱스 항목도 과금되므로 트래픽이 많은 쿼리는 반환 문서만 세지 말고 Query Explain으로 확인하세요.

필요하다면 authorName, commentCount, likeCount, thumbnailUrl, lastActivityAt 같은 목록 표시용 필드를 문서에 미리 저장해 반복 조회를 줄이세요. 피드, 검색 결과, 관리자 테이블에는 명확한 limit을 두어 한 번의 동작에서 발생할 수 있는 read 상한을 예측 가능하게 만드세요.

페이지네이션은 offset보다 cursor를 권장합니다. Firestore는 offset으로 건너뛴 문서도 read로 과금하지만 cursor는 마지막으로 본 문서 다음부터 이어갈 수 있습니다. count(), sum(), average() 쿼리는 집계가 무료라고 가정하지 말고 과금되는 인덱스 read를 추정에 포함하세요.

실시간 listener는 결과에 문서가 추가되거나 변경될 때 read가 과금됩니다. 오프라인 persistence 설정과 연결 해제 시간에 따라 재연결 시 문서와 인덱스를 다시 읽을 수도 있습니다. listener 쿼리를 좁게 유지하고 화면이 비활성화되면 구독을 해제하며 모바일 네트워크에서 재연결 동작을 측정하세요.

계산기의 일반 트래픽과 높은 트래픽 시나리오를 Firestore 콘솔의 실제 사용량과 비교하세요. 복잡한 리포트, 관계형 필터, 잦은 집계, 여러 엔티티를 가로지르는 관리자 화면이 read 대부분을 만든다면 Firestore 단독 구조를 확정하기 전에 Cloud SQL과 비교하세요.