MVP 백엔드 비교: Firebase, Supabase, Appwrite 무료 구간은 언제 끝나는가

핵심 요약

• 세 서비스의 무료 구간은 나란히 놓고 비교할 수가 없습니다. 각자 공개하지 않는 축이 서로 다르기 때문입니다. 이 글의 결론이 여기에서 나옵니다.
• Appwrite 는 무료 플랜의 읽기·쓰기 한도를 가격 페이지에 적지 않습니다. 비교표의 읽기·쓰기 행에 Pro 와 Enterprise 값만 있고 Free 칸은 비어 있습니다.
• Firebase 무료 플랜에는 함수와 클라우드 스토리지가 아예 없습니다. Spark 칸이 "Not applicable" 입니다. 흔히 인용되는 월 200만 호출은 유료 Blaze 의 무료 구간이지 Spark 의 한도가 아닙니다.
• Firebase 는 Firestore 읽기·쓰기 단가도 페이지에 없습니다. "이후 Google Cloud 가격" 이라고만 적고 외부로 넘깁니다.
• 그래서 공개된 값만으로 "무료가 언제 끝나는가" 를 계산할 수 있는 곳은 Firebase 와 Supabase 둘뿐입니다. Firebase 는 하루 2,500화면, Supabase 는 텍스트 문서 25만 건입니다. 계산에 쓴 가정은 본문에 그대로 적었습니다.
• 가격표에 안 적힌 조건이 실제로는 더 자주 문제가 됩니다. Supabase 와 Appwrite 의 무료 프로젝트는 7일 동안 아무도 안 쓰면 멈춥니다.
• 모든 수치는 2026년 8월 19일에 공개 가격 페이지에서 확인한 값입니다. 페이지에 없는 값은 없다고 적었고 다른 데서 가져오지 않았습니다.

문제 정의: 무료로 시작하는데 언제부터 돈이 나가나

MVP 백엔드 비교를 할 때 대부분 기능표부터 봅니다. 인증이 되는지, 실시간이 되는지, 파일 저장이 되는지를 확인합니다. 그런데 초기 서비스에서 기능 차이가 결정을 가르는 경우는 드뭅니다. 셋 다 웬만한 건 됩니다.

실제로 결정을 가르는 건 다른 질문입니다. 무료로 얼마나 버틸 수 있고, 무료가 끝나는 순간이 언제 오느냐입니다. 이걸 모르면 두 가지가 생깁니다. 사용자가 늘기 시작한 바로 그 시점에 서비스가 멈추거나, 예상 못 한 청구서를 받습니다.

이 글은 세 서비스의 공개 가격 페이지를 직접 열어 확인한 기록입니다. 네 가지 기준으로 봤습니다. 무료 구간 한도, 먼저 닿는 한도, 초과 단가, 가격표에 없는 조건입니다. 성능, 기능 완결성, 개발 편의는 이 글에서 다루지 않습니다. 그 축들이 덜 중요해서가 아니라, 한 글에서 다 다루면 아무것도 제대로 못 보기 때문입니다.

무료 구간에 무엇이 들어 있나

각 서비스의 무료 플랜 한도입니다. 항목 이름이 서비스마다 달라서 비슷한 것끼리 묶었습니다.

표를 만들면서 알게 된 것이 있습니다. 빈칸이 생각보다 많습니다. 아래에서 "명시 없음" 은 제가 못 찾은 것이 아니라 그 페이지의 무료 플랜 칸이 실제로 비어 있다는 뜻입니다.

출처는 각 서비스의 공개 가격 페이지이며 2026년 8월 19일에 확인했습니다. Firebase, Supabase, Appwrite.

이 표에서 가장 중요한 것은 채워진 칸이 아니라 빈칸입니다. 세 서비스가 서로 다른 항목을 안 알려주기 때문에, 같은 축으로 나란히 놓는 일 자체가 안 됩니다.

Appwrite 는 무료 플랜의 읽기·쓰기 한도를 안 적습니다. 가격 페이지의 Databases 비교표에 Reads 와 Writes 행이 있는데, Pro 와 Enterprise 칸에만 값이 있고 Free 칸은 비어 있습니다. 유료 초과 단가는 10만 읽기당 $0.060, 10만 쓰기당 $0.10 으로 적어놓았으므로 세는 것 자체는 합니다. 무료에서 몇 건까지인지를 안 밝히는 것입니다.

Firebase 는 무료 플랜에 함수와 클라우드 스토리지를 아예 안 넣습니다. Cloud Functions 의 Spark 칸과 Cloud Storage 의 Spark 칸이 둘 다 "Not applicable" 입니다. 흔히 인용되는 월 200만 호출은 유료 Blaze 플랜의 무료 구간이지 Spark 의 한도가 아닙니다. 무료로 백엔드 로직을 돌릴 생각이었다면 Firebase 는 그 시점에 이미 유료입니다.

Supabase 는 셋 중 무료 구간 표가 가장 채워져 있습니다. 읽기·쓰기를 안 세고 용량으로 거는 구조라 셀 항목 자체가 적기도 하지만, 적어놓은 것은 다 적어놓았습니다.

무료가 끝나는 지점을 계산해봤습니다

한도를 실제 사용량으로 바꿔봤습니다. 가정을 먼저 적습니다. 이 값이 여러분 서비스와 다르면 결과도 달라지므로, 산식을 그대로 적어둡니다.

• 화면 하나를 열 때 문서 읽기 20건 (목록형 화면 기준)
• 텍스트 문서 하나 평균 2KB
• 페이지 하나 전송량 500KB (이미지 포함)

Appwrite 행을 빈칸으로 둔 것은 조사를 덜 한 것이 아닙니다. 계산에 넣을 숫자가 공개되지 않았습니다. 다른 블로그나 커뮤니티에 도는 값을 옮겨 적으면 표는 채워지지만, 그 값이 지금 유효한지 확인할 방법이 없습니다. 무료 한도를 계산해야 하는 상황이라면 Appwrite 는 문의를 넣거나 직접 계정을 만들어 사용량 화면을 봐야 합니다.

전송량 한도는 셋 다 비슷한 자리에 있습니다. Supabase 와 Appwrite 가 월 5GB 이고, Firebase 는 Firestore 쪽이 월 10GiB 입니다. 페이지당 500KB 로 잡으면 5GB 는 월 1만 페이지뷰입니다. 이미지가 많은 서비스라면 위 표의 한도보다 이쪽이 먼저 옵니다.

두 숫자의 성격이 서로 다르다는 점도 중요합니다.

Firebase 의 한도는 하루 단위입니다. 월 한도가 아니라 일 한도라서, 한 달 총량이 여유로워도 특정 하루에 몰리면 그날 끊깁니다. 마케팅을 돌린 날이나 어디 소개된 날이 위험합니다. Hosting 전송량도 일 360MB 로 같은 구조입니다.

Supabase 의 한도는 쌓이는 양입니다. 읽기와 쓰기 횟수를 안 세는 대신 데이터가 쌓여서 500MB 를 넘으면 끝납니다. 시간이 가면 반드시 도달한다는 뜻입니다. 다만 텍스트만 쌓으면 25만 건이라 초기에는 여유가 있습니다. 이미지는 별도 파일 저장(1GB)에 들어가므로 데이터베이스 용량과 따로 셉니다.

무료를 벗어나면 어떻게 되나

과금 구조가 갈립니다. Supabase 와 Appwrite 는 월 25달러라는 바닥이 생기고 그 위에 초과분이 붙습니다. 예측이 쉽습니다. Firebase 는 바닥이 없는 대신 상한도 없습니다. 트래픽이 튀면 청구서도 튑니다. 신규 가입자에게 300달러 크레딧을 주는데, 페이지에 "if eligible" 이라는 조건이 붙어 있습니다.

여기서 하나 짚고 가겠습니다. Firebase 가격 페이지는 Firestore 읽기와 쓰기의 단가를 안 보여줍니다. "무료 일 5만 읽기, 이후 Google Cloud 가격" 이라고만 적고 외부 페이지로 넘깁니다. Hosting 전송량과 함수 호출은 페이지에 숫자가 있는데 데이터베이스 작업만 없습니다.

이게 실무에서 문제가 됩니다. 읽기와 쓰기가 Firestore 요금의 가장 큰 부분인데, 그 단가를 알려면 Google Cloud 가격 페이지를 따로 열어 리전별 표를 봐야 합니다. 이 글에서는 Firebase 의 읽기·쓰기 초과 요금을 계산하지 않습니다. 확인한 페이지에 없는 숫자를 옮겨 적을 수는 없습니다.

정리하면 세 곳이 각각 다른 것을 숨깁니다. Firebase 는 무료 구간을 밝히고 초과 단가를 숨깁니다. Appwrite 는 초과 단가를 밝히고 무료 구간을 숨깁니다. Supabase 는 양쪽 다 밝힙니다. 셋 중 하나만 골라 총비용을 미리 계산할 수 있다면 Supabase 입니다.

원화 환산도 하지 않았습니다. 환율과 시점을 확인하지 않은 상태로 환산하면 그 숫자부터 틀리기 시작합니다.

가격표에 없지만 실제로 걸리는 것들

세 페이지를 나란히 놓고 보니 표에 잘 안 잡히는 조건이 몇 개 있었습니다.

Supabase 와 Appwrite 의 무료 프로젝트는 7일 비활성이면 멈춥니다. 이게 실무에서 제일 자주 문제가 됩니다. MVP 를 만들어두고 투자자나 고객을 만나러 다니는 동안 아무도 안 들어가면 프로젝트가 일시정지됩니다. 데모를 보여주려고 링크를 열었는데 안 뜨는 상황이 생깁니다.

Appwrite 무료는 용량이 아니라 개수로 걸립니다. 프로젝트당 데이터베이스 1개, 버킷 1개, 함수 2개입니다. 저장 공간이 2GB 로 넉넉해도 함수를 세 개 쓰려면 그 시점에 유료로 넘어갑니다. 파일 하나의 크기 상한도 50MB 이고, 로그는 1시간만 남습니다.

Firebase 의 Hosting 전송량은 일 단위입니다. 앞에서도 말씀드렸지만 다시 적습니다. 월 환산으로 계산하면 안 됩니다.

Firebase 무료 플랜에 함수가 없다는 점은 다시 짚어야 합니다. 백엔드 로직을 서버에서 돌려야 하는 서비스라면 Firebase 는 시작부터 Blaze 입니다. 카드를 등록해야 하고, 그 순간부터 상한 없는 종량제 안에 들어갑니다. 무료로 버틸 생각으로 골랐다면 전제가 어긋납니다.

MVP 백엔드 비교, 결국 무엇으로 고르나

무료 구간만으로 백엔드를 고르라는 글이 아닙니다. 팀이 익숙한 것, 필요한 기능, 나중에 옮기는 비용이 더 크게 작용할 수 있습니다. 다만 무료 구간이 결정에 들어와야 한다면 순서는 이렇습니다.

1. 서버에서 돌릴 로직이 있는지 먼저 봅니다. 있으면 Firebase 무료 플랜은 후보에서 빠집니다. 함수가 Spark 에 없기 때문입니다. 이 한 줄로 후보가 셋에서 둘로 줄어드는 경우가 많습니다.
2. 내 서비스에서 가장 빨리 늘어나는 것이 무엇인지 정합니다. 읽기 횟수인지, 쌓이는 데이터인지, 전송량인지를 봅니다. 읽기 횟수라면 공개된 한도가 있는 Firebase 만 미리 계산이 됩니다. 쌓이는 데이터라면 Supabase 의 500MB 가 기준점입니다.
3. 하루 한도인지 월 한도인지 확인합니다. 트래픽이 고르지 않은 서비스라면 일 한도가 있는 쪽이 불리합니다.
4. 비용 예측이 필요한지 봅니다. 투자 전이라 지출 상한이 중요하면 정액 구조를 권장합니다. 갑자기 튀는 것을 감당할 수 있으면 종량제가 싸게 끝날 수도 있습니다.
5. 데모를 얼마나 자주 여는지 봅니다. 만들어두고 며칠씩 안 쓰는 상태가 반복되면 7일 일시정지 조건이 실제 문제가 됩니다.

무료 구간만으로 결정하지 마시라는 당부를 한 번 더 드립니다. 다만 가격 페이지에서 무엇이 비어 있는지를 보는 습관은 남기실 만합니다. 채워진 숫자보다 빈칸이 더 많은 것을 말해주는 경우가 있습니다.

이 글의 모든 수치는 2026년 8월 19일에 확인한 값입니다. 세 서비스 모두 가격을 바꿉니다. 결정하기 전에 원 페이지를 다시 열어보시는 편이 안전합니다.

관련 글

발행된 글이 쌓이면 여기에 관련 글을 연결합니다.

---

출처

• Firebase Pricing (Google, 확인 2026-08-19)
• Supabase Pricing (Supabase, 확인 2026-08-19)
• Appwrite Pricing (Appwrite, 확인 2026-08-19)