직접 써보고 결정해보는 Firebase vs Supabase

https://medium.com/@thesagarkale/firebase-vs-supabase-2c2541ae9bd

개요

jiujitsu-chart 프로젝트 개발을 위해 인증/인가 및 데이터베이스 연동을 담당할 백엔드 서비스를 선택하는 과정에서 여러 가지 옵션을 검토했고, 최종적으로 가격, 구현 난이도, JavaScript 지원 여부를 고려해 Firebase와 Supabase 두 가지로 선택지를 좁힐 수 있었다.

 

하지만 쉽게 둘 중 하나를 선택하기 어려웠고, 개인 사용 경험과 함께 일부 블로그글, 공식 문서를 참고하며 고민한 과정을 글로 정리하고자 한다.

비교

🤑 가격

Firebase와 Supabase는 둘 다 다양한 가격 플랜을 제공하고 있으며, 프로젝트의 규모와 요구 사항에 따라 가격이 달라질 수 있다.

따라서, 개발하려는 서비스의 요구 사항을 정확히 파악하고, 이에 가장 적합한 백엔드 서비스를 선택하는 것이 중요하다.

 

• Firebase Pricing

Firebase Pricing

• Supabase Pricing

Pricing & Fees | Supabase

 

 

내가 관심있었던 항목은 API request 와 DB 용량에 대한 청구 비용이었다.

 

	Firebase	Supabase
API request	read 50,000 회 무료 / 초과 시 100,000 회 당 $0.031 write 20,000 회 무료 / 초과 시 100,000 회 당 $0.094 delete 20,000 회 무료 / 초과 시 100,000 회 당 $0.01	unlimited
Storage size	1 GB 까지 무료 / 초과 시 1 GB 당 $0.156	무료 플랜 500 MB 유료 플랜 (월 $25) 8 GB / 초과 시 1 GB 당 $0.125

 

나에겐 아직 수익화를 하지 못하는 단계에서 지출을 발생시키고 싶지 않았기 때문에 무료 플랜에서도 충분히 운영할 수 있도록 하는 것이 관건이었다.

 

Supabase 의 가장 큰 장점 중 하나는 api request 횟수에 대한 비용 청구를 하지 않는다는 점이다.

내가 관리하려는 데이터도 모두 크기가 크지 않은 JSON 이기 때문에, Supabase의 무료 플랜에서 제공하는 500MB의 스토리지로도 충분할 것으로 판단했다.

 

'가격' 항목 Supabase 승.

🔓 인증

Server Side 처리

이번 프로젝트에서는 Next.js app router를 활용하여 Server Component의 이점을 최대한 활용하고자 했다. 이를 위해 클라이언트에 불필요한 로직이 내려가는 것을 방지하고, 가능한 한 서버 사이드에서 인증 요청 및 확인을 처리하도록 구현했다.

 

기본적으로 두 서비스 모두 SDK를 통한 인증 요청 및 확인은 클라이언트에서 동작하도록 설계되어 있다. 인증 정보를 검증한 후, 불필요한 추가 요청을 방지하기 위해 인증 정보가 유지된다. (브라우저 localStorage, sessionStorage 에 sid 저장)

 

하지만 서버 사이드에선 별도의 처리가 필요하다. 보통 서버 사이드에선 session 과 cookie에 인증 정보를 저장하여 이를 처리한다.

하지만 cookie와 session을 직접 관리하는 일은 매우 매우 귀찮은 일이므로, 이미 구현되어있는 라이브러리를 사용하고자 했다.

 

• Firebase
  • https://github.com/gladly-team/next-firebase-auth
  • https://github.com/nextauthjs/next-auth
• Supabase
  • https://www.npmjs.com/package/@supabase/ssr

 

Firebase 의 경우에는 third party library 에서 이를 지원하는데, app router 미지원, firebase 와 연동을 위한 추가 작업 등의 이슈가 있었다.

반면 Supabase 는 베타 버전이긴하지만 자체적으로 라이브러리를 제공하는 만큼 사용이 수월했다. app router 내의 Server, Client Component 에서도 잘 동작했고 가이드 문서도 잘 작성되어있기에 적용하기에 큰 어려움이 없었다.

 

Error 객체 전달 방식

사소하긴 하지만 Try, catch 문을 사용하지 않아도 되는 Supabase 의 방식이 좀 더 편리했다. 😂

• Firebase

signInWithPopup(auth, provider)
  .then((result) => {
    const user = result.user;
  }).catch((error) => {
    // 에러 헨들링
  });

 

• Supabase

// try, catch 구문을 사용하지 않아도 되어서 편리하다
const { data, error } = await supabase.auth.getUser()

 

'인증' 항목 Supabase 승.

 

💾 데이터베이스

Firebase 와 Supabase 는 다른 유형의 데이터베이스를 제공한다.

 

Firebase 는 NoSQL 데이터베이스인 Firestore 을 제공한다. 사실상 JSON 구조를 그대로 데이터베이스에 저장한다고 생각해도 될 만큼 유연하다. 이는 개발자가 SQL을 몰라도 손쉽게 데이터를 다룰 수 있게 해주며, 스키마를 사전에 정의할 필요 없이 신속하게 애플리케이션에 적용할 수 있는 장점을 제공한다. 따라서 복잡하지 않은 데이터 구조를 갖는 애플리케이션을 빠르게 개발할 때 매우 유용하다.

 

Supabase 는 PostgreSQL을 기반으로 한 오픈소스 데이터베이스를 사용한다. 관계형 데이터베이스이므로, 스키마를 정의하고 테이블 간의 관계를 설정할 수 있다. 이는 복잡한 데이터 모델링과 SQL 기반의 고급 쿼리에 강점을 갖는다. 

 

하지만, 실제 사용자들의 후기를 살펴보면, Firebase와 Supabase 간의 선택은 단순히 기능적인 차이뿐만 아니라 사용자의 취향과 경험에 따라 달라질 수 있을 것 같다. 

결론적으로, 사이드 프로젝트 수준에서는 두 서비스 중 어느 것을 선택해도 큰 차이가 없으므로 본인이 선호하는 방식을 선택하면 될 것 같다.

 

'데이터베이스' 항목 무승부

 

🧐 그 밖의 이슈들

소셜 로그인

 

나는 로그인을 소셜 로그인으로 구현하고자 했고, Provider로는 Google 을 선택했다. 이러한 기능 또한 Supabase에서 제공한다.

그런데 소셜 로그인 시도시 이동되는 화면이 조금 이상했다. 

스캠 사이트...?

 

나에게는 마치 개인정보를 탈취해가는 스캠 사이트의 도메인 url처럼 보였다. 😂

나와 같은 불만을 느끼는 사용자들이 있었지만, 결론은 노출되는 도메인을 바꾸고 싶다면 유료 플랜을 사용해야한다. 

 

• https://github.com/orgs/supabase/discussions/5041

Continue to custom.domain instead of XXXX.supabase.co when using Google as provider · supabase · Discussion #5041

 

Firebase 는 문제없이 domain을 변경할 수 있는 것으로 확인된다. (테스트는 안해봄)

 

https://www.oladimeji.es/p/setting-up-firebase-oauth-for-websites

Using a custom domain for firebase OAuth screens

 

'소셜 로그인' Firebase 승

 

Firebase document read count 누적 이슈

 

firebase 를 사용해보며 깜짝 놀랬던 점은 firestore read count가 생각보다 빠르게 찬다는 것이었다.

분명히 document read는 한 두번 정도만 발생했던 것 같은데 콘솔에서는 100 이 넘는 수치가 찍혀 있었다.

 

아무리 생각해도 이상해서 조사해본 결과, 나와 같은 의아함을 가진 사람들이 있었다. 

 

• https://stackoverflow.com/questions/50887442/cloud-firestore-how-is-read-calculated

결론은 Firebase Database 탭에 접근하는 것만으로도 document read 카운트로 집계된다는 것이다. 개발 중에는 Database 탭에 접근하여 데이터가 제대로 업로드됐는지 확인해볼일도 많을텐데, 이 정도 속도라면 무료 플랜의 상한인 50,000 카운트는 빠르게 초과될 것 같다라는 생각이 들었다. 

위에서 언급했다시피 Supabase 는 api reqeust 에 제한이 없다.

 

개발 콘솔 접근 경험 Supabase 승

결론

글을 작성하다 보니, 나의 단편적인 경험을 바탕으로 판단한 경향이 있는 것 같기도 하다. 실제로 Supabase는 아직 조금 버그가 있는 감이 있다. 그리고 스타트업에서 서비스하기 때문에 갑자기 서비스가 중단되거나 Heroku 처럼 무료 플랜 지원 중단에 대한 막연한 불안감도 있다.

 

하지만 현재 상황에서 위의 항목에서 더 많은 우위를 차지한 Supabase를 선택하였고, 사용하고 있는 지금까지도 후회는 없다! 😎