Firestore vs Realtime Database: 어느 것이 가장 좋고 왜?

Source: Dev.to

Firebase는 두 가지 데이터베이스를 제공합니다:

• Realtime Database – 원래의 JSON‑트리 데이터베이스
• Cloud Firestore – 최신 문서 지향 데이터베이스

두 데이터베이스 모두 실시간 동기화와 오프라인 작동을 지원하지만, 각각 다른 요구에 맞게 설계되었습니다. 아래는 간단한 비교와 제가 개인적으로 선택한 이유입니다.

빠른 개요

Realtime Database: 무엇이며 언제 빛을 발하는가

What it is – 하나의 거대한 JSON 트리입니다. /users/uid/profile 혹은 /chats/chatId/messages 와 같은 경로에서 읽고 씁니다. 데이터는 중첩되어 있으며, 경로를 구독하면 해당 경로 아래의 모든 데이터를 반환합니다(깊이를 제한하려면 얕은 읽기(shallow reads)를 사용할 수 있습니다). “필드별 쿼리”는 없으며, 경로 자체가 쿼리 역할을 합니다.

Strengths

• Simple – 컬렉션도 인덱스도 없습니다. 경로만 읽고 쓰면 됩니다. 작은 앱이나 프로토타입에 적합합니다.
• Very low latency – 직접 경로에 접근하므로 고빈도 업데이트(예: 접속 상태, 커서 위치, 실시간 점수)에 이상적입니다.
• Cheap at small scale – 저장소 + 대역폭 요금이 데이터와 트래픽이 적을 때 Firestore의 작업당 과금 모델보다 저렴할 수 있습니다.
• Tiny SDK – 번들 크기가 작아 제약이 있는 환경에 유용합니다.

Weaknesses

• No real queries – “role = admin인 모든 사용자” 혹은 “createdAt > X인 메시지”와 같은 쿼리를 할 수 없습니다. 경로를 읽은 뒤 클라이언트에서 필터링하거나 데이터를 크게 비정규화해야 합니다.
• Scaling & depth limits – 깊은 트리와 넓은 fan‑out(예: 한 번의 쓰기로 많은 노드를 수정) 구조는 확장성이 떨어집니다; 데이터를 평탄화하거나 분할해야 할 수 있습니다.
• Tree‑only structure – 관계형 및 다대다 구조가 어색해 중복 데이터와 추가 동기화 로직이 많이 필요합니다.

When I use it

• 간단한 실시간 앱(접속 상태, 기본 채팅, 실시간 카운터)
• 프로토타입이나 개념 증명
• 데이터가 자연스럽게 트리 구조를 이루고 쿼리 요구가 최소인 경우
• 이미 Realtime Database 기반으로 구축된 프로젝트이며 마이그레이션이 타당하지 않은 경우

Source:

Firestore: What It Is and When It Shines

What it is – A document database. Data lives in collections (e.g., users, chats); each document has an ID and key‑value (and nested) data. Documents can contain subcollections (e.g., chats/chatId/messages). Queries use where, orderBy, limit, and compound indexes. Real‑time listeners work on collections or query results.

Strengths

• Rich queries – “Users where role == 'admin'”, “messages where chatId == X orderBy createdAt limit 50”. Server‑side querying and explicit indexes make complex data access easy.
• Scales better – Multi‑region, automatic scaling, no single‑tree bottleneck. Ideal for many collections and complex access patterns.
• Clearer data model – Collections and documents map well to entities and relationships, reducing the need for heavy denormalization.
• Strong offline support – Queries and listeners work offline with persistence, just like Realtime Database.

Weaknesses

• Pricing can bite – You pay per read/write/delete. Heavy read traffic (e.g., “list all items” on every screen load) can become expensive without caching or pagination.
• More setup – Indexes, security rules, and data modeling require more upfront thought than “just a path.”
• Slightly higher latency – Flexible queries involve more processing than a single‑path read, though the difference is usually negligible.

When I use it

• Most new Firebase projects
• Anything that needs filtering, pagination, or multiple views over the same data
• Apps expected to grow in data volume and query complexity

나란히 비교: 주요 차이점

어느 것이 당신에게 가장 적합한가?

• 빠른 프로토타입이 필요하거나 간단한 실시간 기능을 원하거나 이미 Realtime Database 프로젝트에 깊이 관여하고 있다면 Realtime Database를 사용하세요. 가볍고, 규모가 작을 때 비용이 저렴하며, 단순 경로 읽기에 초저지연을 제공합니다.*

• 새로운 앱을 구축하고 성장할 예정이며, 복잡한 쿼리, 페이지네이션이 필요하거나 보다 명확한 데이터 모델을 원한다면 Firestore를 선택하세요. 확장성, 쿼리 기능, 다중 지역 복원력이 뛰어나 장기적으로 더 안전한 선택이지만, 가격 및 인덱싱을 보다 신중하게 관리해야 합니다.

최고? 나의 추천

오늘날 대부분의 앱에 대해: Firestore가 더 나은 기본값입니다.

이유

• 쿼리 – 거의 모든 앱은 결국 “조건에 따라 아이템 가져오기” 혹은 “페이지네이션이 있는 정렬된 리스트”가 필요합니다. Firestore는 이를 기본적으로 지원하고, Realtime Database는 우회 방법과 비정규화를 강요합니다.
• 스케일링 – 앱이 성장하면 Firestore가 함께 확장됩니다. Realtime Database는 구조적 한계에 도달할 수 있어 큰 리팩터링이 필요할 수 있습니다.
• 데이터 모델 – 문서와 컬렉션은 사용자, 채팅, 게시물 등을 생각하는 방식과 일치합니다. 유지보수와 팀원 온보딩이 더 쉽습니다.
• 생태계와 미래 – Google은 Firestore에 투자하고 있습니다(멀티 리전, 향상된 툴링). Realtime Database는 안정적이지만 새로운 기능이 먼저 도입되는 곳은 아닙니다.

Realtime Database가 여전히 최선인 경우

• 극히 단순한 실시간 전용 – 존재 여부, 실시간 카운터, 혹은 거의 쿼리가 필요 없는 작은 트리. 단순함과 지연 시간이 유연성보다 중요합니다.
• 극소 규모에서 엄격한 비용 – 읽기/쓰기 거의 없고 가장 작은 비용을 원한다면 Realtime Database의 가격이 더 낮을 수 있습니다.
• 기존 Realtime Database 앱 – 마이그레이션에는 비용이 듭니다. 현재 앱이 단순하고 안정적이라면 Firestore의 쿼리와 스케일이 필요할 때까지 Realtime Database를 유지해도 괜찮습니다.

요약

• Firestore를 새 프로젝트와 쿼리가 필요하거나 성장할 가능성이 있는 모든 경우에 사용하세요.
• Realtime Database를 단순한 경로 기반 실시간 앱이나 이미 사용 중이며 마이그레이션이 정당화되지 않을 때 사용하세요.

실제로 “어떤 것이 최선인가” = 대부분의 경우 Firestore; 특정하지만 실제적인 사용 사례에 대해서는 Realtime Database.

Saad Mehmood — Portfolio