Convex는 기존 DB와 무엇이 다를까? Postgres·Firebase·Supabase 비교 | DAKER 커뮤니티
Convex는 데이터베이스 쿼리를 SQL이 아닌 TypeScript 함수로 작성하고, 데이터가 바뀌면 그 쿼리를 구독한 화면이 자동으로 갱신되는 오픈소스 반응형(reactive) 데이터베이스입니다. Postgres·MySQL 같은 전통적인 DB가 "데이터를 저장하고 SQL로 꺼내는 곳"이라면, Convex는 데이터베이스와 서버 함수, 실시간 동기화 클라이언트를 한 묶음으로 제공하는 백엔드에 가깝습니다. 이 글은 Convex 공식 문서와 공식 비교 페이지, GitHub 저장소를 바탕으로 기존 DB 솔루션과의 차이를 정리합니다.
Convex란 무엇인가: 쿼리가 곧 TypeScript 코드
Convex 공식 문서는 Convex를 이렇게 소개합니다.
Convex는 쿼리가 데이터베이스 안에서 바로 실행되는 TypeScript 코드인 오픈소스 반응형 데이터베이스입니다. React 컴포넌트가 상태 변화에 반응하듯, Convex 쿼리는 데이터베이스 변화에 반응합니다. (Convex Overview)
프로젝트를 만들면 convex/ 폴더가 생기고, 여기에 읽기 전용 query, 읽고 쓰는 트랜잭션 mutation, 외부 API를 부르는 action 함수를 작성합니다. 데이터는 JSON처럼 중첩된 문서를 테이블에 넣고, 다른 테이블의 문서를 ID로 참조합니다. 공식 문서는 이를 "문서-관계형(document-relational)" 데이터베이스라고 부릅니다. 연결 설정이나 클러스터 관리 없이 프로젝트 생성과 동시에 DB가 준비되고, SQL이나 ORM은 쓰지 않습니다.
차이 1. 실시간 구독이 기본값입니다
전통적인 DB에서 화면을 실시간으로 갱신하려면 폴링, 별도 실시간 서버, 캐시 무효화 로직을 직접 붙여야 하는 경우가 많습니다. Convex에서는 React의 useQuery 훅으로 쿼리를 부르면 클라이언트가 WebSocket으로 그 결과를 구독합니다. Convex는 쿼리 함수가 DB에서 읽은 데이터를 추적했다가, 관련 데이터가 바뀌면 쿼리를 다시 실행해 새 결과를 밀어 줍니다. 여러 쿼리의 결과도 DB의 같은 시점으로 함께 갱신되므로, 재고 수와 장바구니 수처럼 서로 맞아야 하는 숫자가 잠깐이라도 어긋나 보이지 않는다는 것이 공식 설명입니다.
차이 2. 트랜잭션을 따로 선언하지 않습니다
Postgres나 MySQL에서는 BEGIN·COMMIT으로 트랜잭션 범위를 정하고, 격리 수준과 잠금을 신경 써야 합니다. Convex에서는 mutation 함수 하나 전체가 곧 트랜잭션입니다. 공식 문서에 따르면 Convex는 직렬화 가능(serializable) 격리와 낙관적 동시성 제어(OCC)를 씁니다. 충돌이 나면 Convex가 함수를 자동으로 다시 실행하는데, 이것이 가능한 이유는 query와 mutation이 네트워크 요청 같은 비결정적 동작을 할 수 없도록 막혀 있기 때문입니다.
낙관적 다중 버전 동시성 제어 DB는 흔히 스냅샷 격리를 보장하지만, Convex의 구현은 진짜 직렬화 가능성을 제공해 어떤 트랜잭션이 동시에 들어와도 올바른 결과를 냅니다. (OCC and Atomicity)
그 대신 결제 API 호출이나 LLM 호출 같은 외부 작업은 action에서 하고, DB를 읽고 쓸 때는 action이 query·mutation을 호출하는 구조를 따라야 합니다.
차이 3. 데이터 접근은 전부 백엔드 함수를 거칩니다
Firebase(Firestore)는 클라이언트가 DB에 직접 접근하고 보안 규칙으로 막는 방식이 일반적입니다. Convex는 모든 데이터 접근이 백엔드 함수를 통해서만 이뤄지므로, 공개할 데이터를 일반 TypeScript 코드로 걸러 내면 됩니다. Convex는 공식 비교 페이지에서 이 점을 "복잡한 보안 규칙이 필요 없다"고 설명합니다(Convex vs. Firebase). 스키마도 처음엔 없이 시작했다가, 나중에 TypeScript 스키마를 고정해 배포 시점에 저장된 데이터와 맞는지 검증받는 "점진적 엄격함"을 택할 수 있습니다.
Convex와 기존 DB 솔루션 한눈에 비교
아래 표는 Convex 공식 문서와 Convex가 직접 만든 비교 페이지(vs. Supabase, vs. Firebase)의 내용을 정리한 것입니다. 경쟁 제품에 대한 평가는 Convex 측 관점이라는 점을 감안해 읽어 주세요.
| 항목 | Convex | Postgres·MySQL | Supabase | Firebase |
|---|---|---|---|---|
| 쿼리 언어 | TypeScript 함수 | SQL | SQL(Postgres) | SDK 쿼리 |
| 실시간 갱신 | 기본 내장(쿼리 구독) | 직접 구현 | 별도 Realtime 서버 | 지원 |
| 트랜잭션 | mutation 전체가 자동 트랜잭션 | 직접 선언 | 직접 선언(Postgres) | Convex 비교표상 "기본값 아님" |
| 데이터 모델 | 문서-관계형 | 관계형 | 관계형 | 문서형 |
| 스키마 | 선택 후 강제 가능 | SQL 스키마 필수 | SQL 스키마 | 강제 없음 |
| SQL·확장 생태계 | 없음 | 풍부 | Postgres 확장 사용 | 없음 |
Convex를 고를 때 따져 볼 점
장점만 있는 것은 아닙니다. Convex는 SQL을 지원하지 않으므로, 기존 SQL 분석 도구나 Postgres 확장, 오래 쌓인 SQL 자산을 그대로 쓰기 어렵습니다. Convex 비교 페이지도 SQL 지원과 Postgres 확장, 엣지 함수는 Supabase 쪽 강점으로 적어 두었습니다. 또 쿼리 안에서 외부 요청을 못 하는 등 함수 종류별 제약에 맞춰 코드를 나눠야 합니다.
운영 측면에서 Convex 클라우드는 PlanetScale의 MySQL을 저장 계층으로 쓰고, 오픈소스 버전은 SQLite·Postgres·MySQL을 지원합니다. 백엔드는 대부분 Rust로 작성됐고 get-convex/convex-backend 저장소로 공개되어 있어 직접 호스팅도 가능합니다. 이 저장소는 2026년 10월 15일 기준 GitHub 별 약 1만 2,700개입니다. 다만 라이선스는 MIT 같은 일반 오픈소스가 아니라 FSL-1.1-Apache-2.0으로, 호스팅 Convex Cloud와 경쟁하는 제품을 만드는 것만 제외하고 Apache-2.0 수준으로 쓸 수 있으며 코드는 작성 2년 뒤 Apache-2.0으로 전환됩니다(Self Hosting).
AI 대회·해커톤 참가자에게 주는 의미
해커톤처럼 짧은 시간에 동작하는 데모를 만들어야 할 때, Convex는 DB 연결·실시간 서버·트랜잭션 처리를 직접 짜지 않아도 된다는 점이 큰 장점입니다. 공식 문서는 쿼리가 TypeScript이고 트랜잭션 보장이 강해서 AI가 생성한 코드도 데이터를 망가뜨리기 어렵다고 설명합니다. 반대로 대용량 데이터를 SQL로 분석해야 하거나 기존 Postgres 기반 시스템과 붙여야 한다면 Postgres나 Supabase가 더 자연스러운 선택일 수 있습니다. 실시간 협업 화면이 핵심인지, SQL 분석이 핵심인지부터 정하고 고르면 됩니다.
출처
- Convex Docs, Convex Overview: https://docs.convex.dev/understanding/
- Convex Docs, OCC and Atomicity: https://docs.convex.dev/database/advanced/occ
- Convex Docs, Self Hosting: https://docs.convex.dev/self-hosting
- Convex, Convex vs. Supabase: https://www.convex.dev/compare/supabase
- Convex, Convex vs. Firebase: https://www.convex.dev/compare/firebase
- get-convex/convex-backend GitHub 저장소: https://github.com/get-convex/convex-backend
- Convex 공식 로고: https://www.convex.dev/brand