프로덕션 데이터베이스가 100K 레코드에 도달하면 쿼리 시간이 급상승하기 시작합니다. 대시보드를 새로고침하면 — 이전에는 300ms에 렌더링되던 필터링된 목록이 이제 2.4초가 걸립니다. 클라이언트가 관리자 패널이 더 느려진 이유를 묻습니다. Supabase, Firebase, PlanetScale, Neon 또는 Turso가 실제로 이 규모를 처리할 수 있는지 평가할 시간입니다. 대부분의 비교 글은 todo 앱을 만들고 연구라고 부릅니다. 우리는 1년 이상 Supabase PostgreSQL에서 5개의 라이브 클라이언트 사이트에 걸쳐 253,000+ 레코드를 실행하고 있습니다. Firebase Firestore, PlanetScale, Neon, Turso를 실제 프로젝트와 실제 트래픽 패턴으로 테스트했습니다. 여기 규모에서 실제로 깨지는 것과 그렇지 않은 것들이 있습니다.

100K+ 레코드를 복잡한 쿼리, 실시간 기능, 인증으로 처리해야 하는 웹 애플리케이션을 구축하고 있다면, 데이터베이스 선택이 앞으로 몇 년간 아키텍처를 정의할 것입니다. 잘못 선택하면 6개월 후 데이터 계층을 다시 작성하거나 3배 더 많은 돈을 지불해야 합니다. 나는 두 가지 모두에서 당신을 구하고 싶습니다.

목차

Best Database for 100K+ Record Websites: Supabase vs Firebase vs PlanetScale Tested

이 비교가 존재하는 이유

Social Animal에서 우리는 헤드리스 웹 애플리케이션을 구축합니다 — 주로 Next.js와 Astro로 — 동적이고 데이터가 많은 사이트가 필요한 클라이언트들을 위해. 50K+ 목록이 있는 엔터프라이즈 디렉토리, 수천 개의 페이지를 생성하는 프로그래밍 방식의 SEO 사이트, 실시간 업데이트가 필요한 SaaS 대시보드를 생각해보세요.

클라이언트가 100K+ 레코드와 관련된 프로젝트로 우리에게 올 때, 데이터베이스 대화는 첫 날부터 발생합니다. 사후 생각이 아닙니다. 데이터베이스 선택은 인증 전략, API 설계, 호스팅 비용, 6개월 후 기능을 배포할 수 있는 능력에 영향을 미칩니다.

모든 5개 데이터베이스에서 동일한 프로덕션 워크로드를 실행했다고 가장할 생각은 없습니다. 그건 거짓말입니다. 제가 한 것은 Supabase에서 심각한 프로덕션을 실행하는 것입니다 (253K+ 레코드, 5개 사이트, 14개월). 그리고 특정 클라이언트 프로젝트에 대해 대안을 철저히 기술적으로 평가했습니다. 어떤 데이터가 프로덕션에서 오고 어떤 데이터가 평가에서 오는지 명확히 하겠습니다.

한 눈에 보는 경쟁사들

깊이 들어가기 전에 빠른 그림입니다:

  • Supabase — PostgreSQL with batteries included (인증, 스토리지, 실시간, 엣지 함수)
  • Firebase Firestore — Google의 NoSQL 문서 데이터베이스 with 우수한 모바일 SDK
  • PlanetScale — 데이터베이스 분기 기능이 있는 서버리스 MySQL (Vitess 기반)
  • Neon — 분기 및 scale-to-zero를 갖춘 서버리스 PostgreSQL
  • Turso — 엣지에서의 분산 SQLite (libSQL 기반)

각각은 무언가에 진정으로 좋습니다. 질문은 그 무언가가 당신이 구축하는 것과 일치하는지입니다.

Supabase PostgreSQL: 우리의 프로덕션 주력

우리가 가장 깊은 경험을 가진 곳이 Supabase이므로 여기서 시작하겠습니다. 5개의 프로덕션 사이트에 걸쳐, 우리의 가장 큰 테이블에는 137K 행이 있습니다 (디렉토리 프로젝트를 위한 국가 주소 시스템). 그리고 우리는 모든 데이터베이스에 걸쳐 253K+ 총 레코드에 있습니다.

우리가 매일 사용하는 것

**Row Level Security (RLS)**는 아마도 우리가 거래를 체결한 기능입니다. 멀티테넌트 애플리케이션을 구축할 때 — 대부분의 헤드리스 CMS 기반 사이트가 결국 그렇게 됩니다 — 사용자별 데이터 격리가 필요합니다. RLS를 사용하면 보안 로직이 데이터베이스 자체에 있습니다. API 계층이 모든 단일 쿼리에서 user_id로 필터링하는 것을 기억할 필요가 없습니다. 데이터베이스가 그것을 시행합니다.

우리 프로젝트에서 일반적인 RLS 정책은 다음과 같습니다:

-- 사용자는 자신의 조직 목록만 볼 수 있습니다
CREATE POLICY "org_isolation" ON listings
  FOR SELECT
  USING (org_id = (SELECT org_id FROM profiles WHERE id = auth.uid()));

-- 관리자는 모든 것을 볼 수 있습니다
CREATE POLICY "admin_access" ON listings
  FOR ALL
  USING (EXISTS (
    SELECT 1 FROM profiles
    WHERE id = auth.uid() AND role = 'admin'
  ));

이것은 실제 SQL입니다. 소유 DSL이 아닙니다. Supabase를 떠나야 할 필요가 있다면, 이 정책들은 PostgreSQL 호스트로 변환됩니다.

pgvector는 의미론적 검색을 위해 계시를 받았습니다. 우리는 기존 전체 텍스트 검색이 충분하지 않은 콘텐츠가 많은 사이트에 이를 구현했습니다. 사용자가 "downtown near places to eat"을 검색하면 레스토랑, 카페, 푸드 트럭을 포함한 결과를 기대할 것입니다 — 이 정확한 단어가 목록에 없더라도.

-- 벡터 열 생성
ALTER TABLE listings ADD COLUMN embedding vector(1536);

-- 인덱스 생성 (100K+ 레코드에서 정말 중요합니다)
CREATE INDEX ON listings USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 100);

-- 의미론적 검색 쿼리
SELECT id, name, 1 - (embedding <=> $1) AS similarity
FROM listings
WHERE 1 - (embedding <=> $1) > 0.78
ORDER BY embedding <=> $1
LIMIT 20;

1536차원 벡터가 있는 137K 레코드에서, 이 쿼리는 Supabase의 Pro 플랜에서 ~45ms에 반환됩니다. 그것은 실시간 검색-입력하면서-검색을 위해 빠르기에 충분합니다.

PostGIS 지리-쿼리는 우리의 위치 기반 기능을 강화합니다. 반경 내 목록 찾기, 거리순 정렬, 운전 시간 계산 — 모두 애플리케이션 코드 대신 데이터베이스 수준에서 처리됩니다.

-- 포인트로부터 10km 내의 목록 찾기, 거리순으로 정렬
SELECT id, name,
  ST_Distance(location, ST_MakePoint(-73.9857, 40.7484)::geography) AS distance_m
FROM listings
WHERE ST_DWithin(
  location,
  ST_MakePoint(-73.9857, 40.7484)::geography,
  10000
)
ORDER BY distance_m
LIMIT 50;

Realtime 구독은 WebSocket 인프라 없이 라이브 대시보드를 구축할 수 있게 해줍니다. 클라이언트의 관리자 패널은 관련 테이블의 INSERT 이벤트를 구독하기 때문에 새로운 제출이 즉시 나타납니다. 추가 인프라가 없습니다.

완벽하지 않은 것

나는 Supabase가 완벽하지 않다고 주장하지 않을 것입니다. 100K+ 행이 있는 테이블을 탐색할 때 대시보드가 느릴 수 있습니다. 테이블 편집기는 작은 데이터셋에는 괜찮지만 대량 작업에는 고통스럽습니다 — SQL을 직접 사용할 것입니다. 그들의 Edge Functions는 Deno로 구동되므로, 일부 Node.js 패키지는 작동하지 않습니다. 그리고 서버리스 환경에서 연결 풀링이 필요하면, 그들의 Supavisor 연결 문자열을 사용해야 합니다 (2025년 초부터 PgBouncer를 사용하지 않습니다).

또한, 그들의 무료 계층은 개발을 위해 진정으로 관대하지만 500MB 데이터베이스 공간의 하드 제한이 있습니다. 100K+ 레코드가 있는 프로덕션의 경우, 최소 Pro 플랜 ($25/월)을 찾고 있습니다.

Best Database for 100K+ Record Websites: Supabase vs Firebase vs PlanetScale Tested - architecture

Firebase Firestore: 장점과 단점

우리는 2024년에 2개의 클라이언트 프로젝트에 대해 Firebase를 진지하게 평가했습니다. 하나는 오프라인 동기화 요구 사항이 있는 모바일 우선 애플리케이션이었습니다. 다른 하나는 복잡한 필터링을 갖춘 디렉토리 사이트였습니다.

Firebase가 진정으로 승리하는 곳

Firebase의 모바일 애플리케이션용 실시간 동기화는 여전히 최고 수준입니다. 오프라인 지속성, 자동 충돌 해결, iOS/Android SDK와의 긴밀한 통합은 주요 플랫폼이 모바일인 경우 명백한 선택입니다. Google Auth 통합은 죽은 간단합니다 — 몇 줄의 코드와 Sign-in with Google, Apple, 전화번호, 이메일/비밀번호가 있습니다.

Firebase Crashlytics, Remote Config, Analytics는 모바일 개발 생태계를 형성하고 다른 것은 일치하지 않습니다. 주요 플랫폼이 모바일이고 웹 앱이 두 번째라면, Firebase는 심각한 고려를 받을 가치가 있습니다.

대신 Supabase를 선택한 이유

Firestore는 문서 데이터베이스입니다. 조인이 없습니다. 잠깐, 그 말을 소화해보세요.

카테고리, 태그, 위치, 리뷰, 사용자 프로필이 있는 목록의 디렉토리를 구축할 때, 관계형 데이터가 필요합니다. Firestore에서, 당신은 모든 것을 비정규화합니다 (문서 간 데이터 복제). 혹은 여러 라운드 트립 쿼리를 만들고 애플리케이션 코드에서 데이터를 조인합니다.

각각의 "카테고리별로 목록 찾기 평균 등급 포함" 쿼리는 다음과 같습니다:

-- Supabase: 한 쿼리, 완료
SELECT l.*, c.name AS category_name,
  AVG(r.rating) AS avg_rating,
  COUNT(r.id) AS review_count
FROM listings l
JOIN categories c ON l.category_id = c.id
LEFT JOIN reviews r ON r.listing_id = l.id
WHERE c.slug = 'restaurants'
GROUP BY l.id, c.name
ORDER BY avg_rating DESC
LIMIT 20;

// Firestore: 세 쿼리 + 클라이언트 측 조인
const categorySnap = await db.collection('categories')
  .where('slug', '==', 'restaurants').get();
const categoryId = categorySnap.docs[0].id;

const listingsSnap = await db.collection('listings')
  .where('categoryId', '==', categoryId).get();

// 이제 각 목록에 대한 리뷰 가져오기...
// 그다음 애플리케이션 코드에서 평균 계산...
// 그다음 정렬... 당신은 아이디어를 얻습니다.

그리고 여기 진짜 걸림돌입니다: Firestore는 문서 읽기당 요금을 부과합니다. 그 트리플 쿼리 패턴은 모든 쿼리의 모든 문서를 계산합니다. 100K+ 레코드와 중간 트래픽에서 당신의 청구서는 진정으로 예측 불가능해집니다. 우리는 개발자가 예상보다 더 많은 문서를 스캔하고 있다는 것을 깨닫지 못한 $400+ 놀라운 청구서의 공포 이야기를 들었습니다.

Firestore는 pgvector나 PostGIS와 동등한 것이 없습니다. 기본 geohash 쿼리를 할 수 있지만, 진정한 공간 인덱싱에 비해 근사하고 제한됩니다.

PlanetScale: 훌륭한 데이터베이스, 불완전한 플랫폼

PlanetScale은 Vitess를 밑에서 실행합니다 — YouTube의 데이터베이스를 강화하는 동일한 기술. 순수 MySQL 성능을 위해, 그것은 우수합니다. 그들의 데이터베이스 분기 기능 (분기 생성, 스키마 변경, 다시 병합)은 진정으로 혁신적이고 Supabase가 기본적으로 가졌으면 하는 것입니다.

PlanetScale이 잘하는 것

그들의 서버리스 드라이버는 빠릅니다. 연결 관리는 당신을 위해 처리됩니다. 이것은 서버리스 환경에서 엄청나게 중요합니다. 각 함수 호출은 그렇지 않으면 새로운 데이터베이스 연결을 열 수 있습니다. 스키마 분기는 데이터베이스 마이그레이션을 Git pull 요청처럼 느끼게 합니다 — 안전하고, 검토 가능하고, 되돌릴 수 있습니다.

MySQL 전문 지식이 강한 팀이 기존 웹 애플리케이션을 구축하는 경우, PlanetScale은 견고합니다.

누락된 것

PlanetScale은 단지 데이터베이스입니다. 그것뿐입니다. 완전한 애플리케이션 스택을 구축하는 데 필요한 것과 비교하세요:

| 기능 | Supabase | PlanetScale + 추가 || |---------|----------|---------------------| | 데이터베이스 | ✅ 포함 | ✅ 포함 | | 인증 | ✅ 포함 | ❌ Clerk ($25+/mo) 또는 Auth0 필요 | | 파일 스토리지 | ✅ 포함 | ❌ S3 또는 Cloudflare R2 필요 | | Realtime | ✅ 포함 | ❌ Pusher 또는 Ably 필요 | | 벡터 검색 | ✅ pgvector | ❌ 사용 불가 | | 지리 쿼리 | ✅ PostGIS | ❌ 기본 MySQL 공간 | | 엣지 함수 | ✅ 포함 | ❌ 별도 배포 필요 |

인증을 위해 Clerk, 스토리지를 위해 S3, 실시간을 위해 Pusher, 벡터 검색을 위해 별도 벡터 데이터베이스를 추가할 때쯤, 당신은 1개 서비스 대신 5개를 관리하고 있습니다. 당신의 청구서는 더 높고, 당신의 복잡성은 더 높고, 당신의 디버깅 표면 영역은 거대합니다.

PlanetScale은 또한 2024년 4월에 그들의 무료 계층 (Hobby 플랜)을 중단했으므로, 진입점은 이제 그들의 Scaler 플랜을 위한 $39/월입니다. 이것은 Supabase Pro보다 더 비싸고 더 적은 기능을 제공합니다.

Neon: 순수주의자의 선택

Neon은 PostgreSQL만 필요하다면 내가 선택할 데이터베이스입니다. 그들의 서버리스 아키텍처는 진정으로 인상적합니다 — scale-to-zero는 당신의 데이터베이스가 쿼리되지 않을 때 아무것도 지불하지 않는다는 뜻입니다. 그들의 분기 기능은 미리보기 배포에 우수합니다 (모든 PR에 대해 데이터베이스 분기 회전).

Neon은 pgvector와 PostGIS를 지원합니다. 표준 PostgreSQL이기 때문입니다. 그래서 당신은 벡터 검색과 지리 쿼리를 얻습니다. 원시 데이터베이스 능력은 Supabase와 거의 동일합니다.

우리가 여전히 Supabase를 선택한 이유

Neon은 데이터베이스입니다. Supabase는 플랫폼입니다. Neon에서, 당신은 추가해야 합니다:

  1. 인증 — Clerk, Auth0, 또는 직접 구축
  2. 스토리지 — S3, Cloudflare R2, 또는 유사
  3. Realtime — Pusher, Ably, 또는 사용자 정의 WebSocket 서버
  4. 엣지 함수 — Cloudflare Workers 또는 Vercel에서 별도로 배포

일부 팀에 대해, 모듈식 접근은 실제로 선호됩니다. 인증에 대해 이미 의견이 있다면 (그리고 Clerk에 대한 예산), S3을 모든 것에 사용하고, 실시간이 필요하지 않다면, Neon의 집중된 접근은 더 적은 공급업체 잠금을 의미합니다.

하지만 우리의 헤드리스 개발 프로젝트에 대해, 한 대시보드, 한 청구서, 한 세트의 API 키에 인증, 스토리지, 실시간을 가지는 것은 가치가 있습니다. 개발자 속도는 빡빡한 일정에 클라이언트 프로젝트를 배포할 때 문제입니다.

Neon의 가격도 경쟁력 있습니다: 그들의 무료 계층은 0.5GB 스토리지와 190 계산 시간/월을 포함합니다. 19$/월의 Launch 플랜은 10GB를 제공합니다. 순수 데이터베이스 플레이의 경우, 그것은 서버리스 PostgreSQL에서 최고의 가치입니다.

Turso: 엣지-퍼스트 SQLite

Turso는 매력적인 기술입니다. 그들은 SQLite — 세계에서 가장 배포된 데이터베이스 — 를 가져가고 그것을 분산했습니다. 당신의 데이터는 엣지에, 사용자와 가깝게 살고, 이것은 읽기 레이턴시가 믿을 수 없을 정도로 낮을 수 있다는 의미입니다 (전역적으로 10ms 미만).

Turso가 빛나는 곳

글로벌 관객을 가진 읽기 중심 워크로드. 자주 변경되지 않는 콘텐츠를 전세계 사용자에게 제공하고 있다면, Turso의 엣지 복제는 데이터베이스 읽기를 즉각적으로 느끼게 합니다. 그들의 임베드 복제 기능은 SQLite 복제를 당신의 애플리케이션에 직접 번들링할 수 있게 합니다.

Astro로 구축된 가벼운 데이터 계층이 필요한 정적 사이트의 경우, Turso는 매력적입니다.

우리의 필요를 맞지 않은 이유

우리의 100K+ 레코드 워크로드는 상당한 쓰기를 수반합니다 — 사용자 제출, 관리자 업데이트, 리뷰 생성, 실시간 데이터 변경. SQLite의 쓰기 모델 (단일 작성자)은 규모에서 병목이 됩니다. Turso는 그들의 libSQL 포크를 통해 이것을 더 잘 처리하지만, 그것은 여전히 쓰기 중심 100K+ 레코드 애플리케이션을 위해 설계되지 않았습니다.

벡터 검색이 없습니다. PostGIS 동등물이 없습니다. PostgreSQL 또는 MySQL과 비교하여 제한된 생태계. 우리의 디렉토리 및 SaaS 프로젝트에 대해, 이것들은 거래 중단자였습니다.

헤드-투-헤드 기능 비교

2026년 중반까지의 우리의 프로덕션 경험과 평가에 기반한 전체 비교 테이블입니다:

기능 Supabase Firebase PlanetScale Neon Turso
데이터베이스 유형 PostgreSQL NoSQL (Firestore) MySQL (Vitess) PostgreSQL SQLite (libSQL)
기본 인증 ✅ 예 ✅ 예 ❌ 아니오 ❌ 아니오 ❌ 아니오
벡터 검색 ✅ pgvector ❌ 아니오 ❌ 아니오 ✅ pgvector ❌ 아니오
지리 쿼리 ✅ PostGIS ⚠️ 제한 (Geohash) ⚠️ 기본 MySQL 공간 ✅ PostGIS ❌ 아니오
Realtime ✅ 예 ✅ 예 ❌ 아니오 ❌ 아니오 ❌ 아니오
파일 스토리지 ✅ 예 ✅ 예 ❌ 아니오 ❌ 아니오 ❌ 아니오
엣지 함수 ✅ Deno 기반 ✅ Cloud Functions ❌ 아니오 ❌ 아니오 ❌ 아니오
조인 / 관계 ✅ 전체 SQL ❌ 조인 없음 ✅ 전체 SQL ✅ 전체 SQL ✅ SQL (제한)
분기 ⚠️ 마이그레이션 경유 ❌ 아니오 ✅ 네이티브 ✅ 네이티브 ❌ 아니오
Scale-to-Zero ❌ 아니오 ✅ 예 ✅ 예 ✅ 예 ✅ 예
가격 예측 가능성 🟢 높음 (평면 계층) 🔴 낮음 (읽기당) 🟡 중간 🟢 높음 🟢 높음
오픈 소스 ✅ 예 ❌ 아니오 ❌ 아니오 (Vitess는) ✅ 예 ✅ 예
자체 호스팅 가능 ✅ 예 ❌ 아니오 ❌ 아니오 ❌ 아니오 ✅ 예

100K+ 레코드에서의 성능 벤치마크

이 숫자들은 137K 행의 주요 테이블이 있는 우리의 프로덕션 Supabase 인스턴스 (Pro 플랜, us-east-1 지역)에서 옵니다. 다른 데이터베이스의 경우, 게시된 벤치마크와 100K 합성 레코드를 가진 우리의 평가 테스트를 사용하고 있습니다.

쿼리 유형 Supabase Firebase PlanetScale Neon Turso
ID로 간단한 SELECT 3ms 8ms 4ms 5ms 1ms
필터링된 쿼리 (인덱스) 12ms 15ms 10ms 14ms 3ms
복잡한 JOIN (3 테이블) 35ms N/A (조인 없음) 28ms 38ms 25ms
벡터 유사성 (상위 20) 45ms N/A N/A 42ms N/A
지리 반경 (10km) 22ms ~50ms (geohash) N/A 24ms N/A
전체 텍스트 검색 18ms N/A (Algolia 사용) 15ms 20ms 12ms
대량 INSERT (1000 행) 180ms 250ms 150ms 195ms 320ms
콜드 스타트 (서버리스) N/A (항상 켜짐) ~100ms ~50ms ~300ms ~20ms

몇 가지 것들이 튀어 나옵니다. Turso의 읽기 성능은 예외적입니다 — 그것은 SQLite-at-edge 이점입니다. PlanetScale의 MySQL 엔진은 우리 테스트에서 PostgreSQL보다 JOIN을 약간 더 빠르게 처리합니다. Neon의 콜드 스타트는 주목할 만합니다 (300ms). 데이터베이스를 깨워야 하기 때문입니다. 하지만 후속 쿼리는 빠릅니다. Firebase의 조인 부족은 당신이 문자 그대로 이 쿼리 중 일부를 실행할 수 없다는 것을 의미합니다.

Supabase의 항상 켜진 계산 (Pro에서 scale-to-zero 없음)은 영 콜드 스타트를 의미하고, 이것은 첫 요청이 느릴 수 없는 사용자 대면 애플리케이션에서 문제입니다.

100K 레코드 워크로드 가격 책정 분석

현실적인 100K 레코드 애플리케이션을 모델링해봅시다: 100K 목록이 있는 디렉토리 사이트, 50K 월간 활성 사용자, ~2M 데이터베이스 읽기/월, ~50K 쓰기/월, 5GB 데이터베이스 크기, 10GB 파일 스토리지.

Supabase Pro Firebase (Blaze) PlanetScale Scaler Neon Launch Turso Scaler
기본 비용 $25/mo $0 (종량제) $39/mo $19/mo $29/mo
데이터베이스 포함 (8GB) ~$18 (읽기 + 쓰기) 포함 (10GB) 포함 (10GB) 포함 (9GB)
인증 포함 (50K MAU) 포함 +$25/mo (Clerk) +$25/mo (Clerk) +$25/mo (Clerk)
스토리지 (10GB) 포함 ~$3/mo +$2/mo (R2) +$2/mo (R2) +$2/mo (R2)
Realtime 포함 포함 +$25/mo (Pusher) +$25/mo (Pusher) +$25/mo (Pusher)
추정 총합 $25/mo ~$21/mo ~$91/mo ~$71/mo ~$81/mo

Firebase는 두 가지를 깨닫기 전까지 저렴해 보입니다. 첫째, 그 $21 추정은 예측 가능한 읽기 패턴을 가정합니다. 바이러스 순간 또는 봇이 당신의 사이트를 크롤링하는 것은 읽기를 급증하게 하고 — 당신의 청구서도 급증합니다. 둘째, 벡터 검색과 같은 기능이 필요할 때, 당신은 Pinecone 또는 Weaviate를 추가하고 있고, 이것은 $70/월에서 시작합니다.

Supabase의 평면 $25/월 모든 것 — 데이터베이스, 인증, 스토리지, 실시간, 엣지 함수 — 은 이 워크로드 크기에 대해 놀랍게 좋은 가치입니다. Pro 플랜은 8GB 데이터베이스, 250GB 대역폭, 100GB 스토리지, 인증을 위한 50K 월간 활성 사용자를 포함합니다.

어떤 데이터베이스를 선택할까요?

이것들 도구로 구축한 우리의 진지한 권장은 다음입니다:

Supabase를 선택하세요 — 관계형 데이터를 가진 웹 애플리케이션을 구축하고 있고, 한 플랫폼에서 인증 + 스토리지 + 실시간이 필요하고, PostgreSQL의 생태계를 원하고 (pgvector, PostGIS, 전체 텍스트 검색), 또는 Next.js로 구축하고 있다면. 이것은 우리가 보는 프로젝트의 아마도 80%를 다룹니다.

Firebase를 선택하세요 — 오프라인 동기화 문제가 있는 모바일 우선 애플리케이션을 구축하고 있고, 당신의 팀이 이미 Firebase 생태계를 알고 있고, 또는 당신의 데이터는 진정으로 문서 형태입니다 (채팅 메시지, 활동 피드, 간단한 사용자 프로필).

PlanetScale을 선택하세요 — 당신은 강한 MySQL 팀을 가지고 있고, 복잡한 스키마 관리를 위해 데이터베이스 분기가 필요하고, 그리고 당신은 이미 인증과 스토리지를 위해 별도의 서비스를 사용하고 있습니다. 그것은 훌륭한 데이터베이스입니다 — 단지 완전한 플랫폼이 아닙니다.

Neon을 선택하세요 — 당신은 플랫폼 오버헤드 없이 PostgreSQL을 원하고, 최고 수준의 서비스에서 스택을 조립하는 것을 선호하고, 또는 저트래픽 프로젝트에서 비용 최적화를 위해 scale-to-zero가 필요합니다.

Turso를 선택하세요 — 읽기 중심, 전역적으로 분산된 애플리케이션을 구축하고 있고, 엣지 레이턴시가 쓰기 처리량보다 중요하고, 또는 Astro의 콘텐츠 중심 사이트로 작업하고 있다면.

Social Animal에서 우리의 작업을 위해, Supabase가 올바른 호출이었습니다. 올인원 플랫폼은 더 빠른 개발을 의미하고, 더 간단한 아키텍처, 그리고 예측 가능한 비용. 우리는 253K+ 레코드로 그것을 확장했습니다. 숨도 헐떡이지 않습니다. 이 규모의 프로젝트를 계획하고 있고 아키텍처에 대해 이야기하길 원한다면, 우리에게 연락하세요 — 우리는 이것을 몇 번 했습니다.

FAQ

Supabase는 대규모 애플리케이션에 좋습니까?

예, 그리고 우리는 그것을 뒷받침하는 프로덕션 증거를 가지고 있습니다. 우리는 5개의 프로덕션 사이트에서 Supabase Pro에 253K+ 레코드를 실행하고 있습니다. 쿼리 성능은 일관성 있게 유지됩니다 — 벡터 유사성 검색을 가진 우리의 가장 복잡한 조인은 137K 행에서 50ms 미만에 반환됩니다. Supabase는 표준 PostgreSQL에서 실행되고, 이것은 우리 대부분이 구축할 어떤 것보다 훨씬 큰 규모의 애플리케이션을 강화합니다. 플랫폼 계층 (인증, 스토리지, 실시간)이 더 새롭지만, 2024년 초부터 우리에게 안정적이었습니다.

Supabase 가격 책정은 규모에서 Firebase와 어떻게 비교됩니까?

Supabase는 극적으로 더 예측 가능합니다. 그들의 Pro 플랜은 50K MAU를 위한 인증, 8GB 데이터베이스 스토리지, 250GB 대역폭, 100GB 파일 스토리지를 포함하는 평면 $25/월입니다. Firebase는 문서 읽기, 쓰기, 삭제당 요금을 부과합니다 — 이것은 비용이 매우 변동한다는 뜻입니다. 2M 월간 읽기가 있는 100K 레코드 애플리케이션은 Firebase에서 $15에서 $200+ 사이의 어디든지 비용을 만들 수 있습니다. 쿼리 패턴에 따라. 우리는 페이지가 소셜 미디어에서 공유될 때 Firebase 청구서가 밤새 3배가 되었을 때의 공포 이야기를 들었습니다.

PlanetScale은 100K+ 레코드를 처리할 수 있습니까?

절대 그렇습니다. PlanetScale은 YouTube 규모 워크로드를 강화하는 Vitess를 실행합니다. 100K 레코드를 가진 원시 데이터베이스 성능을 위해, PlanetScale은 우수합니다. 제한은 규모가 아니라 완전성입니다. 당신은 인증, 파일 스토리지, 실시간 업데이트, 벡터 검색을 위해 별도의 서비스를 추가해야 합니다. 그것은 Supabase의 올인원 접근과 비교하여 비용 ($90+/월 총) 과 아키텍처 복잡성을 추가합니다.

pgvector는 무엇이고 왜 그것이 중요합니까?

pgvector는 PostgreSQL 확장입니다. 벡터 임베딩을 직접 데이터베이스에 저장하고 쿼리합니다. 이것은 의미론적 검색을 가능하게 합니다 — 사용자가 의미로 정확한 키워드보다 검색할 수 있습니다. 100K+ 목록이 있는 디렉토리의 경우, "kid-friendly brunch spots"에 대한 검색은 "family restaurant" 또는 "weekend breakfast"로 태그된 결과를 반환할 수 있습니다. 이 단어들이 일치하지 않더라도. pgvector 없이, 당신은 Pinecone ($70+/월) 과 같은 별도의 벡터 데이터베이스가 필요하고, 두 데이터베이스를 동기화한 상태로 유지하는 것을 다룹니다.

Firebase Firestore는 디렉토리 웹사이트에 좋습니까?

솔직히, 아니요. 디렉토리 웹사이트는 본질적으로 관계형입니다. 목록은 카테고리에 속하고, 태그가 있고, 사용자로부터 리뷰를 받고, 복잡한 필터링이 필요합니다 ("show me restaurants within 5 miles with 4+ stars that are open now"). Firestore는 조인을 할 수 없고, 제한된 쿼리 연산자를 가지고, 문서 읽기당 요금을 부과합니다 — 이것은 복잡한 필터링된 쿼리가 빠르게 비싸진다는 뜻입니다. 우리는 디렉토리 프로젝트에 대해 Firestore를 평가했고, 데이터 비정규화와 클라이언트 측 쿼리 해결책 때문에 Supabase와 비교하여 4배의 개발 시간을 추정했습니다.

나의 Next.js 앱을 위해 Neon 또는 Supabase를 사용해야 합니까?

당신이 단지 데이터베이스가 필요하다면, Neon은 더 나은 가치를 제공합니다 (무료 계층은 관대하고, $19/월 Launch 플랜은 견고합니다). 인증, 스토리지, 실시간, 엣지 함수가 필요하다면 — 대부분의 프로덕션 Next.js 앱이 하는 것처럼 — Supabase는 당신을 여러 분리된 서비스를 통합하는 것으로부터 구하고, 전형적인 프로젝트 타임라인을 주중 축약합니다. 우리는 Next.js 개발 프로젝트에 Supabase를 사용하기 때문에 통합 인증과 스토리지는 개발 속도를 주중 축약합니다.

프로그래밍 SEO 사이트에 최고의 데이터베이스는 무엇입니까?

Supabase PostgreSQL. 프로그래밍 SEO 사이트는 구조화된 데이터에서 수천 개의 페이지를 생성합니다. 이것은 빠른 쿼리, 좋은 인덱싱, 복잡한 데이터 관계를 처리할 수 있는 능력이 필요합니다. 우리는 Supabase에 프로그래밍 SEO 사이트를 구축했고, 위치 페이지를 위한 PostGIS, 관련 콘텐츠를 위한 pgvector, 동적 필터링을 위한 전체 텍스트 검색과 함께, 단일 데이터베이스에서 10K+ 페이지를 생성합니다. 평면 가격 책정은 Google 인덱싱에서의 트래픽 급증이 당신의 청구서를 불합리하지 않는다는 뜻입니다.

Turso (libSQL)는 프로덕션 웹 앱에 준비되었습니까?

읽기 중심 애플리케이션의 경우, 예. Turso의 엣지 복제된 SQLite는 전역적으로 놀라운 5ms 미만의 읽기를 제공합니다. 하지만 쓰기 중심 애플리케이션에서 100K+ 레코드 — 사용자가 데이터를 제출하고, 관리자 패널은 업데이트를 처리하고, 리뷰가 지속적으로 들어오는 디렉토리 경우 — SQLite의 단일 작성자 모델은 제한됩니다. Turso는 그들의 libSQL 포크를 통해 이것을 더 잘 처리하지만, 쓰기 중심 워크로드에는 여전히 설계되지 않습니다. 벡터 검색이 없습니다. PostGIS 동등물이 없습니다. PostgreSQL 또는 MySQL과 비교하여 제한된 생태계. 우리의 디렉토리 및 SaaS 프로젝트의 경우, 이것들은 거래 중단자였습니다.