Pick your serverless database, 14 options across the six categories that decide most picks
Your database is the longest-living architectural decision in any new app. The directory filters by category (Postgres / SQLite-at-edge / MySQL / NoSQL / realtime / KV), language, pricing, plus the Postgres-compatibility and edge-ready flags that decide most picks. Every entry gives you a one-line summary, a concrete best-for, an honest skip-this-if, and a paragraph of opinion.
10 SIDE-BY-SIDE COMPARISONS → TOP-5 DECISION HUB →Filter the list
Showing 14 of 14
Supabase
Postgres-based platform: database, auth, storage, edge functions, realtime, vectors. Open source.
CockroachDB
matureDistributed Postgres-compatible SQL. Strong consistency at global scale, relicensed in 2024.
Neon
Serverless Postgres with branching, scale-to-zero, and a deep separation of compute and storage.
Turso
SQLite at the edge, libSQL fork with replication to 30+ regions, embedded-replicas pattern.
Convex
JS-first reactive database, functions are the API, real-time queries by default.
Nile
Multi-tenant-first serverless Postgres with tenant isolation as a primitive.
Tigris
Globally-distributed object storage and database. S3-compatible, no egress fees.
Xata
Serverless Postgres with a higher-level data model layer. Search, file attachments, branching included.
PlanetScale
MySQL-compatible serverless DB built on Vitess. Reintroduced free tier in 2024 after a controversial removal.
Vercel Postgres
Postgres bundled into Vercel, now powered by Neon under the hood.
Cloudflare D1
SQLite-compatible serverless database in Cloudflare's edge runtime. Tight Workers integration.
MongoDB Atlas
The hosted MongoDB platform. Document-oriented, mature, serverless tier available.
Firebase Firestore
Google's document database with real-time sync and tight Firebase-platform integration.
Upstash
Serverless Redis + Kafka with HTTP API. Pay-per-request, edge-friendly.
No databases match your current filters.
The database choice is the easy half, your migration is the hard one
Picking the database is the easy half. The hard half is migrating off the previous one without losing data, designing the schema your future-self will not curse, and getting realtime / vector / multi-region right when those matter. The 30-min call is the right starting place, describe your stack, your scale, your constraints; I tell you what fits.