NoSQL Firebase Realtime Database vs Cloud Firestore 비교하기

리액트 네이티브 앱 개발하면서 어떤 데이터베이스를 사용하는 것이 효율적인지 고민이 많았습니다. 요즘 유행하는 Supabase에 대한 고민도 하였지만 처음 앱 개발하는데 있어서 종합적인 솔루션을 제공하는 구글 firebase 기반의 솔루션을 사용하기로 하고 관련 기능에 대해 검토를 하였습니다.

 

일반적으로 앱 개발 강의를 통해서 많이 접하는 것이 구글 realtime database 였기에 시작은 당연히 realtime database로 선택하고 서비스 개발을 진행하였습니다.

 

하지만 서비스 기획내용이 구체화 되고 기능이 많아 지면서 고민이 생기기 시작했습니다. 구글에서 firestore라는 다른 database도 있기에 realtime database와 어떤 차이가 있고 firestore로 변경하는 것이 맞을지 스터디를 하였습니다.

 

우선 요즘 유행하는 AI 툴에서 두 개의 데이터베이스에 대해 비교해달라고 했습니다.

다음과 같이 정리해서 알려주었습니다.

 

Perplexity 정리 내용

Firebase의 Realtime Database와 Firestore는 React Native 앱 개발에서 실시간 데이터 동기화를 위한 두 가지 주요 NoSQL 데이터베이스 서비스입니다. 각각의 특징과 차이점을 비교해 설명드리겠습니다.

1. 서비스 소개
   Firebase Realtime Database
- JSON 기반 트리 구조: 단일 JSON 트리로 데이터 저장
- 실시간 동기화: 밀리초 단위의 데이터 업데이트 전파
- 오프라인 지원: 로컬 캐싱을 통한 오프라인 작업 후 자동 동기화
- 직접 클라이언트 접근: 별도 서버 없이 클라이언트에서 직접 접근 가능

  Cloud Firestore
- 문서-컬렉션(Document-Collection) 구조: 계층적 문서 모델로 데이터 조직화
- 확장성: 자동 수평 확장 지원(초당 1M 연결 처리)
- 고급 쿼리: 복합 인덱스 기반의 정교한 쿼리 기능
- 멀티 리전 복제: 글로벌 데이터 자동 복제

2. 주요 차이점 비교

특성	Realtime Database	Firestore
데이터구조	단일 JSON 트리	문서-컬렉션 계층 구조
쿼리 기능	기본 필터링만 지원	복합 조건 쿼리 가능
확장성	수동 샤딩 필요(200k 연결 제한)	자동 확장(1M 연결 처리)
트랜잭션	단일 경로 트랜잭션만 지원	다중 문서 트랜잭션 지원
보안	JSON 규칙 기반	IAM + 보안 규칙 조합
가격 정책	저장소 + 대역폭 기반	작업 횟수 + 저장소 종합 과금

3. 장단점 비교

Realtime Database
- 장점:  
  ❶ 초저지연(10ms 미만) 
  ❷ 단순 데이터 모델에 적합
  ❸ 소규모 앱 경제적

- 단점:  
  ❶ 복잡한 쿼리 불가 
  ❷ JSON 트리 관리 어려움
  ❸ 수동 확장 필요

Firestore
- 장점:  
  ❶ 유연한 데이터 모델 
  ❷ 자동 확장 기능
  ❸ 다중 리전 장애 복구

- 단점:  
  ❶ 복잡한 쿼리 시 비용 증가
  ❷ 초기 학습 곡선 존재
  ❸ 단순 앱에서 과잉 기능 가능성

4. 서비스 유형별 추천 데이터베이스

Realtime Database 추천 케이스
- 실시간 채팅 앱: 짧은 지연시간 요구
- IoT 디바이스 모니터링: 단순 센서 데이터 스트리밍
- 소규모 협업 툴: 실시간 위치/상태 공유

Firestore 추천 케이스
- 소셜 네트워크 서비스: 복잡한 사용자 관계 관리
- 이커머스 플랫폼: 상품 필터링/정렬 다수 조건 필요
- 엔터프라이즈 앱: 글로벌 사용자 기반 확장성 요구

 

선택 가이드라인

1. 데이터 구조 복잡도: 단순 ➔ Realtime DB | 복잡 ➔ Firestore
2. 동시 접속자 규모: 20만 이하 ➔ Realtime DB | 이상 ➔ Firestore
3. 쿼리 요구사항: 기본 필터링 ➔ Realtime DB | 다중 조건 ➔ Firestore
4. 예산 제약: 초기 비용 절감 ➔ Realtime DB | 장기적 확장성 ➔ Firestore

두 서비스 모두 React Native와의 원활한 통합을 제공하며, 실제 선택 시 프로토타입 제작을 통해 성능과 비용을 직접 비교해 보는 것이 가장 효과적입니다.

👉 종합하면 간단하고 빠른 속도 요구시 Realtime Database를 사용하고,

     복잡하고, 사용자가 많고, 글로벌 서비스 확장 고려시 firestore 사용을 하면 된다고 합니다.

실제 적용해서 비교해보기

나는 소셜네트워크 서비스를 고려하고 있어서 처음에 시작은 realtime database로 시작하였지만 곧 firestore 로 다시 변경작업을 진행하였습니다.

 

1.  Realtime Database 사용시

특정 데이터의 속성 정보가 하위 단계로 추가되고 있고 데이터 불러올 때 하위 데이터 전체를 불러오기 때문에 효율적이지 않아서 하위 단계가 많을 수록 부적합 해보입니다.

realtime database sample

 

2.  Cloud Firestore 사용하기

 

문서 기반으로 만들어져서 유연한 확장성을 가지게 됩니다. 개발하면서 다양한 아이디어로 서비스가 변경될 때 마다 문서 및 객체의 구조가 변경되어도 가변적으로 변경되어 수용성이 좋습니다.

물론 조심해야할 부분은 구조가 바뀌게 되면 이전의 데이터도 같은 구조를 갖도록 일괄 변경이 되어야 동일한 서비스 제공이 가능합니다. 

아직 개발테스트의 경우 다양한 시도와 변경을 해 볼 수 있습니다.

 

특히 서비스 요구사항에 따라 다양한 방식의 쿼리가 필요한데 firestore에서는 속도 개선을 위해 사전에 인덱싱 작업을 지원합니다.

같은 데이터라도 서비스 메뉴에 따라 다양하게 조합하여 조회를 해야하는데 이럴 경우 사전 인덱스 작업을 통해 조회 속도를 개선하도록 합니다.  새로운 서비스로 인해 속도 저하 문제가 발생되면 firebase에서 색인생성문을 자동으로 만들어 줍니다. 

firestore document sample

 

데이터가 많을 경우 원하는 데이터베이스내에서 데이터를 찾기에 어려움이 존재합니다. firestore에서는 컬렉션에서 필터링 기능을 지원합니다. 컬랙션내의 속성별 조건에 따라 필터링하여 데이터를 볼 수 있어서 데이터 분석에 도움이 많이 됩니다.

realtime database의 경우 필터링 기능을 지원하지 않습니다.

 

아래의 경우는 답글(comments)의 필터 조건으로 createdAt, userId 등 속성 데이터 기준으로 필터링하여 오름차순, 내림차순 등으로 조회가 가능합니다. 

collection filtering

 

indexing

 

쿼리실행시 인덱싱이 필요한 경우 다음과 같은 오류가 발생되고, 인덱싱을 생성하는 URL를 만들어 줍니다.

 

[console 오류 메시지]

Error loading posts: {"code": "firestore/failed-precondition", "message": "[firestore/failed-precondition] The query requires an index.

- 이 에러는 Firestore 복합 인덱스가 필요하다는 것을 나타냅니다. isPublic과 createdAt 필드를 함께 사용하는 쿼리에 대한 인덱스를 생성해야 합니다.
- 이제 Firestore 인덱스를 생성하기 위한 단계를 안내해드리겠습니다:
- 에러 메시지에 포함된 URL을 클릭하세요

아래와 같이 URL이 안내되고, 해당 URL 실행시 firebase firestore 색인생성 페이지로 바로 이동되고, 생성 요청하게되면 자동으로 색인이 만들어집니다.

 

firestore indexing

 

 

그리고 firestore의 rules (규칙)의 제한을 통해 접근 제한 및 등록/수정/삭제 권한을 서비스 특성에 맞게 제한할 수 있어서 안정적 서비스 제공을 가능하게 합니다. 물론 규칙을 만들어서 적용하는게 쉽지는 않기에 AI의 도움을 많아서 작업했습니다.

 

firestore rules

 

실제 서비스를 개발하면서 아직 다 알지는 못하지만, 지금까지 개발하면서  firestore가 관리하는데 어렵기는 하지만 장점이 더 많아 보입니다.

 

앞으로 앱 개발하시는데 다소 도움이 되시길 바랍니다.