Choosing a Database Guide
The SQL-vs-NoSQL debate is mostly settled for typical app backends: start with a relational database unless you have a specific reason not to. Postgres in particular has become the default choice across the industry because it handles relational data, JSON documents (via jsonb), full-text search, and even vector embeddings (via pgvector) in one system — reducing the number of moving parts you need to operate.
The more interesting decision today is where that database runs relative to your compute: a traditional managed instance (RDS, Cloud SQL), a serverless Postgres (Neon, Supabase), or an edge-native database (Cloudflare D1, built on SQLite) that runs colocated with edge functions. Each trades off consistency guarantees, cold-start latency, and operational simplicity differently — the right choice depends on your read/write patterns and where your users are.
When to choose SQL (Postgres/MySQL)
Choose a relational database by default for any app with entities that relate to each other — users, orders, posts, comments — which is nearly every app. Postgres (via AWS RDS, GCP Cloud SQL, DigitalOcean Managed Databases, Supabase, or Neon) is the strongest general default: ACID transactions, mature tooling, jsonb for semi-structured data when you need it, and extensions like pgvector for embeddings. MySQL (via PlanetScale, which adds branching/schema-change workflows, or standard RDS/Cloud SQL) is a solid alternative, particularly if your team has existing MySQL expertise. Choose SQL when you need transactional integrity (payments, inventory counts) or complex joins across entities.
When to choose NoSQL (MongoDB/DynamoDB)
MongoDB (self-hosted or via MongoDB Atlas) fits genuinely document-shaped data with inconsistent schemas across records — content management, catalogs with wildly varying product attributes, or event/log data. AWS DynamoDB is the right call specifically when you need single-digit-millisecond latency at massive, predictable-access-pattern scale and you are willing to design your data model around DynamoDB access-pattern-first modeling (which is a real constraint — you must know your query patterns before you design the table). Do not choose NoSQL just because your data has some flexible fields; jsonb columns in Postgres cover that case for most apps without giving up relational integrity elsewhere.
When to choose edge databases (D1/KV)
Cloudflare D1 (SQLite-based, runs alongside Workers) makes sense when your entire app lives on Cloudflare edge and you want the database physically close to your compute with no separate connection-pooling concern — good for small-to-medium relational workloads, though it is not yet suited for very high write-concurrency or huge datasets. Cloudflare KV (and similarly, Vercel Edge Config) is a key-value store for read-heavy, eventually-consistent data — feature flags, config, cached lookups — not a substitute for a relational database. Use KV/Edge Config for data that is read constantly and written rarely; use D1 or a real Postgres instance for anything transactional.
A practical decision framework
Ask three questions in order. First: does data have relationships that need integrity (orders referencing users, inventory counts)? If yes, use Postgres. Second: is the access pattern read-heavy, rarely-changing, and latency-sensitive (config, flags, cached data)? If yes, add a KV layer (Cloudflare KV, Redis/Upstash) alongside your primary database, do not replace it. Third: is your compute entirely edge-based with modest data volume? Consider D1 to avoid a separate database connection hop. For nearly every app, the answer lands on "Postgres, with an optional KV cache layer" — treat NoSQL and edge-native databases as tools for specific access patterns, not general-purpose defaults.
Frequently asked questions
Is MongoDB or Postgres better for a new app?
Postgres is the better default for most apps because it handles relational data reliably and covers flexible/document-shaped fields via jsonb, giving you NoSQL-like flexibility without giving up transactional integrity. Choose MongoDB specifically when your data is genuinely document-shaped with little cross-entity relationship.
What is Cloudflare D1 and when should I use it?
D1 is Cloudflare serverless SQL database, built on SQLite, designed to run alongside Cloudflare Workers. Use it when your whole app already lives on Cloudflare edge and you want low-latency, colocated data access for small-to-medium relational workloads.
Can I use Cloudflare KV as my main database?
No. KV is a key-value store optimized for read-heavy, eventually-consistent data like config and feature flags. It is not designed for transactional writes or relational queries — pair it with D1 or Postgres as a cache layer, not a replacement.
Do I need DynamoDB for a mobile or web app?
Only if you have massive scale with predictable, well-understood access patterns and need single-digit-millisecond latency — and you are prepared to design your schema around DynamoDB access-pattern-first modeling upfront. Most apps are better served by Postgres.