// REALTIME DATABASE COMPARISON

Best Database for
Realtime Applications

Q: What's the best database for a realtime chat application?

For most chat apps, Supabase or Firebase are excellent choices. They provide built-in realtime subscriptions, presence detection, and handle the WebSocket infrastructure for you. For more control or complex querying needs, use PostgreSQL with Redis pub/sub. Discord famously uses PostgreSQL for message storage with ScyllaDB for high-throughput operations.

Q: Can PostgreSQL handle realtime applications?

Yes! PostgreSQL has built-in LISTEN/NOTIFY for pub/sub functionality. Combined with a WebSocket server, it works well for many realtime use cases. Supabase adds a realtime layer on top of PostgreSQL, making it even easier. Instagram and Notion both use PostgreSQL for their realtime features.

Q: Is Firebase too expensive for realtime apps at scale?

Firebase pricing can be unpredictable with heavy read operations. For chat apps with many small reads, costs can escalate quickly. Alternatives: 1) Use Firebase for auth/hosting but Supabase for database, 2) Implement aggressive client-side caching, 3) Move to self-hosted PostgreSQL + Redis when hitting $500+/month.

Q: How do I handle offline-first realtime syncing?

Firebase Firestore and MongoDB Realm have built-in offline support. For PostgreSQL-based apps, consider: 1) PowerSync for PostgreSQL offline sync, 2) WatermelonDB for local-first with sync, 3) Electric SQL for automatic sync. Always design your data model with conflict resolution in mind.

Q: Should I use WebSockets or Server-Sent Events (SSE)?

Use WebSockets for bidirectional communication (chat, games, collaboration). Use SSE for server-to-client only (notifications, live feeds, dashboards). SSE is simpler, works through proxies better, and reconnects automatically. WebSockets are more flexible but require more infrastructure.

Q: How do realtime databases handle conflicts?

Firebase uses last-write-wins by default but supports transactions. Supabase inherits PostgreSQL's ACID transactions. For true conflict resolution, implement CRDTs (Conflict-free Replicated Data Types) using libraries like Yjs or Automerge. The approach depends on your consistency requirements.

From chat apps to live dashboards: choose the right database for sub-second updates, millions of connections, and seamless sync.

6 Databases

6 Use Cases

14min Read Time

// TL;DR

RECOMMENDATIONS BY USE CASE

Most Common

Chat & Messaging Slack, Discord, WhatsApp

Sub-100ms latency, presence, typing indicators

Recommended Firebase or Supabase

Built-in presence, offline sync, optimistic updates

Scale Millions of concurrent connections

Alternative Redis + PostgreSQL for complex queries

Live Dashboards Analytics, monitoring, trading

High-frequency updates, aggregations

Recommended Redis + PostgreSQL

Redis for speed, Postgres for persistence & queries

Scale 1000s of updates/second

Alternative Supabase for simpler setups

Multiplayer Games Browser games, turn-based, casual

State sync, conflict resolution, low latency

Recommended Firebase or Redis

Firebase for casual, Redis for competitive

Scale 100s of concurrent rooms

Alternative Custom WebSocket + PostgreSQL

Collaborative Editing Google Docs, Figma, Notion

CRDT/OT support, fine-grained sync

Recommended Custom + PostgreSQL

Need specialized conflict resolution algorithms

Scale 100s of concurrent editors per doc

Alternative Yjs/Automerge + any persistence layer

IoT & Telemetry Sensor data, fleet tracking, smart home

High write throughput, time-series

Recommended ScyllaDB or TimescaleDB

Designed for millions of writes/second

Scale Millions of events/second

Alternative InfluxDB for pure time-series

Social Feeds Twitter, Instagram, activity streams

Fan-out, read optimization

Recommended Redis + PostgreSQL

Redis for feed cache, Postgres for persistence

Scale Millions of feed updates/day

Alternative MongoDB for simpler data models

Key insight: Discord uses PostgreSQL. Twitter uses Redis. Firebase powers The New York Times live updates. The "best" database is the one that matches your team's expertise and your specific latency requirements.

// SECTION 01

DATABASE COMPARISON

Scores based on realtime-specific capabilities, not general database features

PostgreSQL + LISTEN/NOTIFY

Rock-solid ACID with native pub/sub

84 avg

Latency

Scalability

Dev Experience

Ecosystem

Cost

100 Best

Realtime Features

Top Pick

Supabase Realtime

Postgres with batteries-included realtime

88 avg

Latency

Scalability

Dev Experience

97 Best

Ecosystem

Cost

Realtime Features

88 Best

Top Pick

Firebase Realtime DB

Zero-config realtime, Google-scale

85 avg

Latency

Scalability

Dev Experience

Ecosystem

94 Best

Cost

Realtime Features

MongoDB Change Streams

Flexible documents with realtime cursors

83 avg

Latency

Scalability

Dev Experience

Ecosystem

Cost

Realtime Features

Top Pick

Redis Pub/Sub + Streams

Blazing fast in-memory messaging

86 avg

Latency

98 Best

Scalability

Dev Experience

Ecosystem

Cost

Realtime Features

ScyllaDB CDC

Cassandra-compatible at extreme scale

80 avg

Latency

Scalability

98 Best

Dev Experience

Ecosystem

Cost

Realtime Features

// SECTION 02

DECISION FRAMEWORK

Answer these questions to find your ideal realtime database

Latency Requirements

< 10ms (competitive gaming) → Redis or ScyllaDB

10-50ms (chat, collaboration) → Firebase or Supabase

50-200ms (dashboards, feeds) → PostgreSQL or MongoDB

Best effort (notifications) → Any database works

Redis delivers sub-millisecond latency. Firebase/Supabase handle most realtime apps. PostgreSQL is fine for less time-sensitive use cases.

Data Model Needs

Complex queries & joins → PostgreSQL (Supabase)

Nested documents → MongoDB or Firebase

Simple key-value → Redis

Wide columns, time-series → ScyllaDB

Your query patterns determine the database. If you need SQL and transactions, start with PostgreSQL. If schema flexibility matters, consider document stores.

Scale Expectations

< 1k concurrent users → Any database works

1k - 100k concurrent → Supabase or Firebase

100k - 1M concurrent → Redis + PostgreSQL

1M+ concurrent → ScyllaDB + Redis

Don't over-engineer. Most apps never exceed 10k concurrent users. Firebase and Supabase scale surprisingly well for their ease of use.

Team Background

SQL experience → PostgreSQL or Supabase

NoSQL / JavaScript → MongoDB or Firebase

Operations expertise → Self-hosted anything

Minimal ops preferred → Firebase or Supabase

Managed services (Firebase, Supabase) eliminate DevOps burden. Self-hosting gives control but requires expertise.

Vendor Lock-in Tolerance

Avoid lock-in → PostgreSQL + custom

Acceptable for speed → Firebase or Supabase

Enterprise requirements → MongoDB Atlas or Postgres

Multi-cloud required → ScyllaDB or CockroachDB

Firebase has highest lock-in. PostgreSQL is portable. Supabase is open-source but managed. Choose based on exit strategy importance.

// SECTION 03

REAL-WORLD SUCCESS STORIES

How top companies build realtime features at scale

FB Firebase

Alibaba

11.11 Shopping Festival

500k+ orders/second

Firebase for realtime inventory updates

The New York Times

Live election results

Millions concurrent readers

Realtime vote count updates

Lyft

Driver location tracking

Millions of location updates

Firebase for passenger-driver sync

SB Supabase

Peerlist

Professional network

100k+ users

Realtime notifications and feeds

Mobbin

Design reference platform

50k+ designers

Collaborative collections

Replicate

AI model marketplace

Millions of predictions

Realtime model status updates

RD Redis

Twitter/X

Timeline caching

500M+ tweets/day

Redis for sub-millisecond feed reads

GitHub

Job queues & caching

100M+ developers

Sidekiq (Redis) for background jobs

Stack Overflow

Caching layer

100M+ monthly visitors

Redis for question/answer caching

PG PostgreSQL

Discord

Message storage

Billions of messages

PostgreSQL + ScyllaDB hybrid

Instagram

Core data layer

2B+ users

Heavily sharded PostgreSQL

Notion

Block storage

Millions of workspaces

PostgreSQL for all persistent data

// SECTION 04

RECOMMENDED TECH STACKS

Complete stacks for different scale requirements

Simple Realtime Stack

Launch in days, scale to 100k users

Supabase Database + Realtime

Postgres + built-in subscriptions, zero config

React/Vue/Svelte Frontend

Supabase has official SDK support

Edge Functions Backend Logic

Serverless, co-located with DB

Supabase Auth Authentication

Integrated RLS policies

Alternative: Firebase + Firestore when Mobile-first or need offline sync

Production Realtime Stack

Battle-tested for serious apps

PostgreSQL Primary Database

ACID transactions, complex queries

Redis Realtime Layer

Pub/sub, caching, session storage

Socket.io / ws WebSocket Server

Reliable connection management

Node.js / Go Backend

Handle high concurrency efficiently

BullMQ Job Queue

Reliable async processing

Alternative: Supabase Realtime when Want managed infrastructure

High-Scale Realtime Stack

Millions of concurrent connections

ScyllaDB Primary Database

Handles millions of writes/sec

Redis Cluster Realtime + Cache

Distributed pub/sub at scale

Kafka Event Streaming

Reliable event ordering at scale

Go / Rust WebSocket Servers

Maximum connections per node

Kubernetes Orchestration

Auto-scale WebSocket pods

Alternative: Pusher / Ably when Want managed WebSocket infrastructure

// SECTION 05

ARCHITECTURE PATTERNS

Common approaches to building realtime systems

Direct Database Subscriptions

Client subscribes directly to database changes

Pros

Simple to implement
Low latency
Automatic sync

Cons

Limited query flexibility
Vendor lock-in
Cost at scale

Database + Message Broker

Database triggers push to message queue, server broadcasts

Pros

Decoupled architecture
Flexible processing
Scalable

Cons

More complex
Additional infrastructure
Potential latency

Event Sourcing

Store events, derive state, broadcast changes

Pros

Complete audit trail
Time-travel debugging
Scalable reads

Cons

Complex to implement
Learning curve
Storage overhead

CQRS + CDC

Separate read/write models, Change Data Capture

Pros

Optimized for each path
Scales independently
Flexible

Cons

Eventually consistent
Complex
More infrastructure

// SECTION 06

PERFORMANCE BENCHMARKS

Real-world latency and throughput comparisons

Metric	PostgreSQL	Supabase	Firebase	Redis	ScyllaDB
Write Latency (p99) Redis fastest, Firebase includes network	5-15ms	10-30ms	20-50ms	< 1ms	1-5ms
Broadcast Latency Time to reach all subscribers	50-100ms	30-80ms	20-50ms	< 5ms	10-30ms
Max Connections/Node Firebase uses Google's edge network	~500	~10k	~200k	~10k	~10k
Writes/sec/Node ScyllaDB designed for write-heavy	~10k	~5k	~100k	~100k	~1M
Cost at 10k MAU Firebase can spike with heavy reads	$20-50/mo	$25/mo	$25-100/mo	$15-30/mo	$100+/mo

Reality check: These benchmarks assume optimal conditions. Real-world latency depends on network, geographic distribution, and your specific query patterns. Always test with your actual use case before committing.

// SECTION 07

COMMON MISTAKES TO AVOID

Learn from failed realtime implementations

Polling instead of pushing

Using setInterval to check for updates every N seconds

Wasted resources, delayed updates, poor UX

Use WebSockets, SSE, or database subscriptions from the start

Broadcasting everything to everyone

Sending all changes to all connected clients

Bandwidth explosion, privacy issues, client overload

Implement proper channel/room-based subscriptions

No connection state management

Assuming WebSocket connections never drop

Lost messages, desync, confused users

Implement reconnection logic with message replay

Skipping optimistic updates

Waiting for server confirmation before UI update

Sluggish feel, poor perceived performance

Update UI immediately, reconcile with server response

Ignoring message ordering

Assuming messages arrive in the order sent

Race conditions, inconsistent state, bugs

Use sequence numbers or vector clocks for ordering

Build This Stack Now

Realtime App with Supabase

npx create-stacksfinder@latest --seed SF1-eyJ2IjoxLCJ0Ijoid2ViLWFwcCIsInMiOiJzdGFydHVwIiwiaHAiOlsic3BlZWQiLCJkeCJdLCJlIjoiamF2YXNjcmlwdCIsInNlbCI6eyJmcmFtZXdvcmsiOiJuZXh0anMiLCJkYXRhYmFzZSI6InN1cGFiYXNlIiwiYXV0aCI6ImJldHRlci1hdXRoIn19 --ref guide-realtime-db

// FAQ

FREQUENTLY ASKED QUESTIONS

Frequently Asked Questions

What's the best database for a realtime chat application?

Can PostgreSQL handle realtime applications?

Is Firebase too expensive for realtime apps at scale?

How do I handle offline-first realtime syncing?

Should I use WebSockets or Server-Sent Events (SSE)?

How do realtime databases handle conflicts?

Build Your Complete Tech Stack

Get personalized database recommendations based on your app's requirements

Start Building Compare Technologies

Best Database for Realtime Applications

RECOMMENDATIONS BY USE CASE

DATABASE COMPARISON

PostgreSQL + LISTEN/NOTIFY

Supabase Realtime

Firebase Realtime DB

MongoDB Change Streams

Redis Pub/Sub + Streams

ScyllaDB CDC

DECISION FRAMEWORK

Latency Requirements

Data Model Needs

Scale Expectations

Team Background

Vendor Lock-in Tolerance

REAL-WORLD SUCCESS STORIES

Alibaba

The New York Times

Lyft

Peerlist

Mobbin

Replicate

Twitter/X

GitHub

Stack Overflow

Discord

Instagram

Notion

RECOMMENDED TECH STACKS

Simple Realtime Stack

Production Realtime Stack

High-Scale Realtime Stack

ARCHITECTURE PATTERNS

Direct Database Subscriptions

Database + Message Broker

Event Sourcing

CQRS + CDC

PERFORMANCE BENCHMARKS

COMMON MISTAKES TO AVOID

Polling instead of pushing

Broadcasting everything to everyone

No connection state management

Skipping optimistic updates

Ignoring message ordering

FREQUENTLY ASKED QUESTIONS

Frequently Asked Questions

Build Your Complete Tech Stack

Best Database for
Realtime Applications