DEVELOPMENT/SUUROUNDINGS

Firestore, CloudSQL, Supabase 가격 정책(2026.07) 및 적정 마진/용량

OSP 2026. 6. 28. 01:39

Firestore, CloudSQL, Supabase 가격 정책(2026.07) 및 적정 마진/용량

 

  • 클라우드 상품 특징은 아래와 같다.
    •   
      상품 요구사항
      		 요약(주요 용례)
      Google Cloud Storage 용량 크고 사용빈도 낮음 외장 인터넷 하드(창고)
      Google Cloud Firebase Firestore 용량 적지 않고
      사용빈도도 됨      		 비관계형 DB(문서) 외장 인터넷 DB
      Google Cloud SQL 관계형 DB(스키마)
      Supabase 관계형 DB(스키마)
      Google Cloud Compute Engine 용량 적고 사용빈도 큰 편 외장 인터넷 CPU(현장인력)
  • Firestore : (https://cloud.google.com/firestore/pricing, https://cloud.google.com/firestore/enterprise/pricing)
    • 요금제(종량제) : 저장용량당 저장료 + 작업횟수당 작업료 + 용량댱 네트워크 요금
    • 더보기

       

      • 요금제는 Standard / Enterprise로 나뉜다.고급쿼리지원 및 MongoDB 호환성에 차이가 있다.
      •   
        종류 요금 (/month)
        기본 모델 1년약정 20%할인모델 3년약정 40% 학인모델
        저장된 데이터 0.15 $ / Gib
        0.24 $ / Gib
        읽기 0.03 $ / 100000 doc
        0.05 $ / 1000000 count        		 0.024 $ / 100000 doc
        0.04 $ / 1000000 count         		0.018 $ / 100000 doc
        0.03 $ / 1000000 count
        쓰기 0.09 $ / 100000 doc
        0.26 $ / 1000000 count         		0.072 $ / 100000 doc
        0.208 $ / 1000000 count         		0.054 $ / 100000 doc
        0.156 $ / 1000000 count
        삭제 0.01 $ / 100000 doc
        0.26 $ / 1000000 count        		 0.008 $ / 100000 doc
        0.208 $ / 1000000 count        		 0.006 $ / 100000 doc
        0.156 $ / 1000000 count
        네트워크 0.15 ~ 0.23 $/GiB -
      • 외장 DB는 유료 크레딧 사용량, 결제 로그 등을 검증/기록하는 용도로 많이 쓰이고, 이러한 경우 결제 또는 유료 기능을 사용시에 접근하기 때문에 저장 용량과 작업 횟수가 크지 않다. 넉넉잡아 한명당 1MB 문서, 하루에 한 번씩 읽고 쓴다고 하면 작업료 (0.00015 + 0.000036 + 0.00018 ~ 0.000366$ /월이 된다. 무료 할당량까지 고려하면 매우 저렴한 편,
        • 구글 클라우드 스토리지 대비 산술적인 저장료는 10배,, 작업료는 10%정도 수준이다.
    • 특징 : 서버리스DB, 확장성, 동시성 문제, 구글
    • 더보기

       

      • 서버리스 DB
        • 호출할 때만 컴퓨팅 리소스를 잠시 빌려서 사용한다. 따라서 서버를 24시간 대기시키는 유지 비용이 없다. 저장/읽기/쓰기/전송에 따라 실제로 사용하는 컴퓨팅 리소스에 맞추어 요금을 지불한다. 
      • 비관계형 DB : noSQL
        • 관계형 DB의 강력한 JOIN기능을 통해서 데이터를 엮을 수 없음. 태그/라벨 같은 N:M 유형의 관계형 데이터 구조를 다루는 서비스에 적합하지 않다. 불가능한 것은 아니지만 관계형 DB를 재발명하는 꼴이 되기 때문. 1:1의 정직, 단순, 심플한 데이터 구조에서 강력하다.
      • 엄격한 스키마가 없음
        • 문서와 컬렉션이라는 JSON 유사 트리 구조로 데이터를 저장하며, 엄격한 스키마가 없기 때문에 문서마다 다른 필드를 가질 수 있어 필드 확장이 용이하다. 대신 데이터 구조의 일관성은 보장받지 못한다.
        • 복잡한 쿼리를 처리하려는 경우 데이터 구조화에 따라 noSQL 조회 기능의 구현 난이도 편차가 매우 크다. 세부 필드 조회 혹은 필드 값에 따른 조건부 조회를 구현하기 어렵다.
      • 트랜잭선 구현상 주의 필요
        • 낙관적 동시성 제어 (Optimistic Concurrency Control)  : 여러 사람이 동시에 같은 문서를 수정1할 때 먼저 끝낸 사람의 것을 반영하고 나중에 시도한 사람의 것은 실패시키고, 이후에 재시도된다. 그러나 단시간에 몰리면 에러를 뱉는다.
        • 반대로 말하면, 동시성 제어가 문제되지 않는 빈도로 사용되는 경우에는 큰 문제가 되지 않는다는 뜻이다. 
      • Google의 온프레미스 인프라 안정성 및 공급 업체 종속성
        • 물리적인 장소와 하드웨어 장비, 관리 인력 및 서비스 유지보수를 Google이 대신 해준다. 그러나 여러 차원에서 구글에 종속된다. Firestore에 정보가 쌓인 상태에서 구글의 가격정책이 급등하거나 구글 자체가 휘청이는 경우, 마이그레이션 리스크가 존재한다.
      • 통합 환경
        • Firestore는 Firebase의 일 서비스로, 사용자 인증(Firebase Authentication), 백엔드 프레임워크(Cloud functions), 푸시알림(Cloud Messaging) 를 다루는 통합 환경에 속한다.
  • CloudSQL (https://cloud.google.com/sql/pricing)
    • 요금제(대여료 + 종량제) : 머신 대여료 + 저장 용량당 저장료 + 작업용량량 네트워크 요금
    • 더보기

       

      • 요금제는 인스턴스 유형에 따라 오픈소스(MySql/PostgreSQL), 라이선스(SQL Server : MSSQL)로 나뉘며, 그 다음은 스펙 + 저장용량 + 작업용량 기반으로 과금된다. 구체적인 도표는 아래와 같다.
      • 비용 구분 비용
        머신 비용 범용  N4 N2 C4A
        CPU
        USD/mon        		 30.149  30.149 39.201  39.42 
        메모리 
        USD / 1GiB*mon        		 5.11  5.11  6.643 6.57 
        인스턴스 비용
        USD / month
        		 micro small
        7.665 25.55
        스토리지 비용
        USD / 1GiB*mon        		 SSD HDD(오픈소스) 백업
        0.17 0.09 0.08
        네트워크 비용
        USD / 1GiB        		 인바운드 아웃바운드
        Free 0.12
        라이선스 비용
        USD / 코어시간        		 Express 웹 Standard Enterprise
        0 0.01134 0.13 0.47
        • 머신 비용은 통째로 빌리 경우, 인스턴스 비용은 쪼개 놓은 추상화 머신 패키지로 빌리는 경우 적용된다. 인스턴스는 토이 프로젝트나 프로토 타입의 비용 절감을 위한 과금 체계로, micro가 그 존재 의의라고 할 수 있다.
        • 머신 과금에는 약정 할인이 있으며(인스턴스는 없다), HA 머신/스토리지는 2배 가격이다.
      • 서버형 DB 특성상 계속 켜놓어야 하기 때문에 가장 싼 micro 요금제로 최소 월 8$ 정도이고, 사용량에 따라 요금이 추가로 부과된다. 온프레미스 대신 제3자의 클라우드를 빌려 쓰는 핵심은 규모의 경제 대신의 단기적인 비용 혜택인데, 그 이점을 제대로 살리지는 못한 요금제로 이해된다. 실제 청구서는 몇만원 수준이라 절대적인 가격이 비싸다고 말할 수는 없지만, 실험적/소형 프로젝트에 지불하기에는 시장 수요가 어떻게 될지도 모르는데 고정비용만 감당하기란 꺼려지기 마련이다.
        • 가격 슬라이드를 그려보자면 규모의 경제 - 단기적인 비용 우위의 중간재 쯤인데, 안타깝게도 지위가 불안한 중간재에 속하는 것으로 보인다.
        • 아래에서 살펴보겠지만, 최소한의 비용을 부담하는 대신 구글의 안정성과 관계형 DB의 장점을 모두 얻는 형국이어서 괜찮은 선택지는 맞다. micro로 하면 비용도 얼마 안 되고.
    • 특징 : 서버DB, 구조성/확장 난이도, 구글/오픈소스
    • 더보기

       

      • 대기형 서버 DB
        • 기본적으로 서버를 통째로 빌리는 개념이기 때문에 아무도 접속하지 않아도 24시간 내내 비용이 계속 부과된다. 평소에 꺼놓고 호출할 때만 키는 요금 절감 방법은 CloudSQL의 On/Off에 몇 분의 로딩이 걸리기 때문에 현실적으로 불가능하다.
      • 관계형 DB : SQL
        • N:M 유형의 데이터 구조를 조직하고 쿼리를 처리함에 있어 매우 강력하다. 얽히고 섥히기 좋은 데이터 구조에서 유리하다.
      • 엄격한 스키마 존재
        • 스키마 불합치 발생이 크래시를 유발한다. 필드 확장은 용이하지 않으나, 전체적으로 동일한 포맷을 강제하는 강력한 규범 덕분에 데이터 구조의 일관성이 보장된다.
        • 복잡한 쿼리를 처리하려는 경우에도 엄격한 스키마와 JOIN 덕분에 매우 간단하다. 세부 필드 조회 혹은 필드 값에 따른 조건부 조회를 구현하기 간단하디.
      • 강력한 트랜잭션
        • SQL의 트랜잭션 안정성 덕분에 데이터 정합성이 강하게 보장된다. 
      • Google의 온프레미스 인프라 안정성 및 공급 업체 종속성 및 오픈소스 개방성으로 완화
        • 물리적인 장소와 하드웨어 장비, 관리 인력 및 서비스 유지보수를 Google이 대신 해준다. 그러나 여러 차원에서 구글에 종속된다. Firestore에 정보가 쌓인 상태에서 구글의 가격정책이 급등하거나 구글 자체가 휘청이는 경우, 마이그레이션 리스크가 존재한다.
        • 오픈소스 관계형 DB 관리 시스템인 Postgres에 기반을 두어 특정 공급업체에 종속되지 않는다. 공급 업체의 가격 정책 변경이나 재무 위기 상황이라도, 경쟁 업체로 인한 마이그레이션 리스크 완화가 기대된다.
      • 통합 환경
        • 과거에는 CloudSQL과 Firebase는 완전 별개의 서비스였으나 현재는 하나의 통합환경 Firebase에 강하게 통합되어 있다.
  • Supabase  (https://supabase.com/pricing)
    • 요금제(구독 + 초과 종량제) : 저장용량당 저장료 + 작업용량당 작업료
    • 더보기
      •  

       

      •  
        종류 요금
        Free Pro  Team 
        구독료 - 기본 25$ / month
        프로젝트당 + 10$ / month         		 기본 599$ / month
        프로젝트당 + 10$ / month 
        프로젝트당 데이터 ~ 500 MB ~ 8GB  이후 0.125 $ / GB Pro와 동일
        총 데이터 ~ 1GB ~ 100 GB 이후 0.0213 $ / GB
        MAU ~ 50000 명 ~ 100000 명 이후 0.00325 $ / MA
        네트워크 Egress ~ 5 GB ~ 250GB 이후 ~0.09 $ / GB
      • Firebase와 비슷한 사용량 기준으로 Pro요금제에서 한 명당 (0.000125 + 0.0000213 + 0.00025 + 0.00009) = 0.0004863$인 셈으로, 산술적으로는 Firebase보다 30%가량 비싸다고 할 수 있다.  
    •  특징 : 서버리스DB, 구조성/확장 난이도, 오픈소스
    • 더보기

       

      • 서버리스 DB
        • 호출할 때만 컴퓨팅 리소스를 잠시 빌려서 사용한다. 따라서 서버를 24시간 대기시키는 유지 비용이 없다. 저장/읽기/쓰기로 쓴 만큼만 요금을 지불한다.   
      • 관계형 DB : SQL
        • N:M 유형의 데이터 구조를 조직하고 쿼리를 처리함에 있어 매우 강력하다. 얽히고 섥히기 좋은 데이터 구조에서 유리하다.
      • 엄격한 스키마 존재
        • 스키마 불합치 발생이 크래시를 유발한다. 필드 확장은 용이하지 않으나, 전체적으로 동일한 포맷을 강제하는 강력한 규범 덕분에 데이터 구조의 일관성이 보장된다.
        • 복잡한 쿼리를 처리하려는 경우에도 엄격한 스키마와 JOIN 덕분에 매우 간단하다. 세부 필드 조회 혹은 필드 값에 따른 조건부 조회를 구현하기 간단하디.
      • 강력한 트랜잭션
        • SQL의 트랜잭션 안정성 덕분에 데이터 정합성이 강하게 보장된다. 
      • 공급업체 비종속성
        • 오픈소스 관계형 DB 관리 시스템인 Postgres에 기반을 두어 특정 공급업체에 종속되지 않는다. 공급 업체의 가격 정책 변경이나 재무 위기 상황이라도, 경쟁 업체로 인한 마이그레이션 리스크 완화가 기대된다.
      • 통합 환경
        • 인증, 스토리지, 백엔드 프레임워크 등을 빠르게 개발할 수 있는 통합 환경이다.
  • 비교
    • 더보기

       

      • 비용 문제
        1. 검증/기록 구현에 사용하려는 경우 검증/기록에 외부 DB를 사용하는 것은 로 컬 디바이스 내부 검증/기록만으로 부족한 경우인데, 보통 유료 기능에 대한 검증/기록에 이용된다. 유료 기능에 대한 보완책으로써 접근하면 모두 절대적인 비용 자체가 상당히 저렴한 편이라 비용 우열은 생략한다. 유료 사용자를 모수로 두고 0.002$ / 명이면, 무시해도 될 것으로 보인다. 
        2. 엔드포인트 단말 연결에 사용되는 경우 : 기기간 데이터 동기화, 메신저 등의 경우에 해당한다. 이 경우는 서비스 특성상 무료 사용자에게도 제공됨이 흔하다. 다만 대부분이 텍스트 자료를 임시 저장하는 형태로 일방의 수신으로 DB에서 삭제하므로 마찬가지로 비용이 저렴하다. 문제라면 모수가 전체 사용자라는 것인데, 네트워크 효과를 기대하는 바이럴 마케팅 비용으로 생각하면 부담스러운 가격은 아니다.
        3. 최소 부담 비용 : 우선 DB 자체가 비싼 요금이라고 말하기는 어렵다. 사용량이 엄청 많아져야 수십만원, 주변에서 재벌 소리 들을 정도여야 수백-수천만원으로, 그 트래픽이 가져오는 수익성으로 커버를 하고도 남는 것이 일반적이다. 그러나 문제는 비용과 수익성이 큰 경우는 경제적으로 클라우드 대신 온프레미스가 선택지로 떠오르기 때문에, 클라우드의 주된 수요처는 소규모 프로젝트라는 것이다. 즉 돈 없는 개발자들의 실험적 수요를 받쳐주어야 하는 것인데, 서버형 DB는 이런 수요에 적절하게 설계되었다고 받아들여지지 않는다. 실질적으로 쓰이지도 않고 있고 앞으로도 쓰일지 아닐지 모르는 서비스를 위해 돈은 계속 지불하라니. 비록 몇만원이지만 선뜻 지갑이 열리지는 않는다.
      • 환경적 트레이드오프  : 구글에 올라 타느냐, 기술에 올라 타느냐 하는 문제로 치환된다. 역사적으로 문맥이 유지되는 것은 기술이지만, 보통 그것을 손에 쥐는 것이 기업이라 쉽지 않은 문제다. CloudSQL은 일방 의존성을 제거하여 구글의 안정성 + 오픈소스의 개방성 모두 기대할 수 있다. 다만 상술했듯 최소 요금이 존재한다. 마치 두 토끼를 모두 잡는 대신 돈을 지불하라 라는 의도된 설계처럼 들리지만, Goolge Cloud에 시초를 두었던 만큼 Cloud 제품군의 레거시 요금 정책에 영향을 많이 받았을 뿐인 것으로 추측한다. 그리고 이러한 레거시 요금 정책이 쫓아내는 수요를 캐치하고 나온 게 Supabase다. 
      • 기술적 트레이드 오프
        •  정합성/동시성 제어 문제 : 이 역시 큰 화두가 되지 못한다. 1인이 단시간에 다수 결제 혹은 다수 유료기능 사용하는 상황은 너무 엣지 케이스다.
        • 4. 확장성/구조화 문제 : 이들을 분리하는 가장 주요한 지점이라 생각한다.
          1. Firebase : "A의 유료 결제 및 유료 기능 크레딧 사용 기록" 정도로 넓게 조회하고 구체적으로는 직접 열어서 확인하는 레거시 로깅 타입. 다각적인 데이터 분석이 어렵다.
          2. CloudSQL 또는 Supabase : "A의 x일 이후 유료 기능 사용 일자 및 크레딧", 또는 "A와 B의 잔여 크레딧이 같은 날짜" 수준의 구조적 조회가 필요한 경우 적절하다. 다각적인 데이터 분석에 수월하다.
      • 요약
        • Firebase : 레거시DB로 족하다.
        • Supabase : 관계형 DB를 최소 비용 없이 쓰고 싶다.
        • CloudSQL : 관계형 DB를 글로벌 공룡 기업 걸로 쓰고 싶다.

       

  •  요약
    • 더보기

       

      •   Firebase CloudSQL Supabase
        데이터 구조 직렬적 1:1 병렬적 N : M 병렬적 N : M
        기술 트레이드오프 및 특징
        NoSQL / SQL        		 쉬운 확장성 강한 정합성 강한 정합성
        정합성 문제 어려운 확장 어려운 확장
        비용 트레이드오프 및 특징
        서버형 / 서버리스        		 최소 비용 0 최소 비용 부담 최소 비용 0
        유효 비용 증가 유효 비용 감소 유효 비용 증가
        환경 트레이드오프 및 특징
        구글 / 오픈소스
        		 구글의 안정성(+) 구글의 안정성 (+) 오픈소스 개방성 (+)
        구글 종속성(-) 오픈소스 개방성 (+) 상대적 불안정성 (-)
        적정 용레 단순한 레거시 로깅
        DB진입/쿼리 단순        		 구조적 데이터
        DB진입/쿼리 구조적        		 구조적 데이터
        DB진입/쿼리 구조적
        비용회피 but
        구글 의존
        + 레거시 DB
        		 비용 부담 but
        병목 의존 제거
        + 관계형 DB
        		 비용 회피 but
        기술 의존
        + 관계형 DB

 

 

 

 

 

 

 

'DEVELOPMENT > SUUROUNDINGS' 카테고리의 다른 글

Google Cloud Compute Engine / Function / Run 가격 정책(2026.07)  (1) 2026.07.02
AI API 가격 정책(2026.06) 및 적정 마진/용량  (1) 2026.06.29
Google Cloud Storage가격 정책(2026.06) 및 적정 마진/용량  (0) 2026.06.26
재무회계 : 매출과 비용률에 따른 순익(률)  (0) 2026.06.24
수익성 핵심지표 : 리텐션(Retention)  (0) 2026.06.23

'DEVELOPMENT/SUUROUNDINGS'의 다른글

  • 현재글Firestore, CloudSQL, Supabase 가격 정책(2026.07) 및 적정 마진/용량

관련글

티스토리툴바