PostgreSQL vs MySQL vs MongoDB 2026 — Database Comparison + Use Case Guide

DATABASE CHOICE 2026 by use case: NEW WEB APP — POSTGRESQL is default 2026. Most-recommended starting point. Reasons: (1) Feature-leader (JSONB, full-text search, pgvector for AI, partial indexes, generated columns, etc.). (2) ACID-compliant + reliable. (3) Massive ecosystem (Supabase, Neon, RDS, all support). (4) Active community + mature. WORDPRESS / LAMP STACK — MYSQL still default. WordPress optimized for MySQL. Drop-in MariaDB if avoiding Oracle. Postgres support for WP exists but ecosystem smaller. AI/ML APPS — POSTGRESQL + pgvector. Avoid separate vector DB until 100M+ vectors. pgvector mature in 2024+. Alternatively: Pinecone (managed), Qdrant (self-host), Redis Stack. MOBILE / EDGE / EMBEDDED — SQLITE. On-device. Files-based. Zero ops. Turso/LiteFS for cloud sync. CACHING / QUEUES / SESSIONS — REDIS or Valkey (Redis fork avoiding RSAL license). Sub-millisecond latency. ANALYTICS / DASHBOARDS — CLICKHOUSE (self-host) or BigQuery (serverless). NOT Postgres for >10M-row analytics. MULTI-REGION GLOBAL APP — COCKROACHDB or YugabyteDB (Postgres-compatible distributed SQL). DOCUMENT-FLEXIBLE / RAPID-CHANGING SCHEMA — POSTGRES JSONB or MongoDB. Postgres JSONB rivals Mongo for 90% of use cases. Mongo for true schema-flexibility + Atlas managed convenience. MASSIVE WRITE SCALE — CASSANDRA or ScyllaDB (faster Cassandra fork). Used by Netflix, Apple, Discord. AWS-NATIVE — DynamoDB if you must AWS-only. Pay-per-request can be cheap. Limited query patterns. RECOMMENDATION HIERARCHY 2026: 1. POSTGRES (default for 80% of apps). 2. SQLITE for embedded. 3. REDIS for cache/queue. 4. ClickHouse/BigQuery for analytics. 5. Mongo only when JSONB + Postgres genuinely insufficient. AVOID: starting with Mongo unless you really need flexible schema + can manage operational complexity.

PERFORMANCE COMPARISON 2026: SIMPLE SELECT queries (one table, indexed): MySQL ~10-15% faster typical. Reason: simpler query planner, less overhead. Affects benchmarks like TPC-C if simple. COMPLEX QUERIES (joins, subqueries, CTEs, analytics): PostgreSQL 2-10x FASTER. Reason: superior query planner, parallel queries, better optimizer for complex scenarios. WRITE THROUGHPUT: similar. PG slightly faster on bulk inserts with COPY. MySQL faster on single-row inserts in some scenarios. CONCURRENCY: PostgreSQL handles high-concurrency much better. MVCC architecture. MySQL row-level locking can cause contention. JSON QUERIES: PG JSONB much faster than MySQL JSON. Indexable via GIN. MySQL JSON is functional but slower querying. FULL-TEXT SEARCH: PG built-in tsvector + tsquery. MySQL has fulltext but less flexible. SCALING READS: both support read replicas. PG has streaming replication, logical replication. MySQL has group replication, replica from binlog. SCALING WRITES: PG via Citus or external partitioning. MySQL via Vitess (YouTube uses) or sharding. STORAGE: MySQL InnoDB row-store. PostgreSQL row-store with TOAST for large objects. ECOSYSTEM 2026: PostgreSQL EXTENSIONS unique advantage — pgvector, PostGIS (geospatial), TimescaleDB (time-series), pg_partman (partitioning), pg_stat_statements (query analysis). MySQL has fewer extensions. CLOUD: managed Postgres available everywhere (AWS RDS, Azure Database, GCP Cloud SQL, Supabase, Neon, Heroku, DigitalOcean). MySQL similarly available. RECOMMENDATION 2026: PostgreSQL for new apps unless WordPress (then MySQL). Migrate MySQL to Postgres if hitting feature limits or complex query slowness. NOT WORTH MIGRATING for performance alone unless specific bottleneck identified.

POSTGRES vs MONGODB 2026 decision: USE POSTGRES (with JSONB) IF: (1) Need ACID transactions across multiple operations (financial, e-commerce). PG has full ACID; Mongo has multi-document transactions but slower. (2) Have RELATIONAL data with some flexible fields. JOIN-heavy queries. (3) Want SQL ecosystem (BI tools, ORM compatibility, reporting). (4) Want one DB instead of multiple (Postgres handles JSON + relations + full-text + vectors). (5) Need strict schema validation. PG strict types + JSONB hybrid. (6) Cost-sensitive — Postgres is FREE OSS. Mongo Atlas managed costs more. USE MONGODB IF: (1) Schema GENUINELY changes frequently with no clean relational model. (2) Document-natural data (user profiles, content with varying fields, IoT JSON streams). (3) Need horizontal sharding more than vertical scale. Mongo native sharding more battle-tested than Postgres Citus. (4) Team already expert in Mongo. (5) Real-time requirements with replica sets + change streams. PERFORMANCE 2026: PG JSONB BENCHMARKS RIVAL or BEAT Mongo for most workloads (per multiple 2024-2025 benchmarks). Mongo wins for very-high-volume document writes. MIGRATION REALITY: many startups began with Mongo (2012-2018 era) + migrated to Postgres later. "We started with Mongo because flexible schema, but we ended up needing more SQL features. Migration was painful." Common pattern. NEW APPS 2026: default to Postgres. Use JSONB for flexible fields. Add Mongo IF JSONB+PG genuinely insufficient. DON'T premature-optimize for "schema flexibility" you may not need. WHO USES MONGO 2026: companies that started in early Mongo era + invested heavily. Toyota, MetLife, Uber (some), Cisco. New companies less likely choose Mongo first. ATLAS MANAGED: Mongo Atlas is the value-add — cluster management, backups, monitoring. If you go Mongo, use Atlas. Self-hosting Mongo painful.

PGVECTOR for AI/ML 2026: pgvector is a Postgres extension for vector embedding storage + approximate nearest neighbor (ANN) search. Mature 2024+. Supports: HNSW indexes, IVFFlat indexes, cosine + L2 + inner-product distance. Hosted by all major Postgres clouds (Supabase, Neon, AWS RDS, GCP). USE CASES: RAG (Retrieval-Augmented Generation) — store document embeddings, retrieve relevant chunks for LLM context. SEMANTIC SEARCH — find similar products, articles, code snippets. RECOMMENDATIONS — embedding-based "users like this also liked". CLUSTERING — group similar customer profiles. PERFORMANCE: HNSW index 100ms-500ms recall@10 for 1M-10M vectors typical. Tradeoff between accuracy + speed configurable. SCALE: Postgres handles 1-100M vectors easily. Beyond 100M consider purpose-built vector DBs. WHEN PGVECTOR ENOUGH: <50M vectors typical web app, RAG for company knowledge bases (most use cases). Combine vectors with relational data (user IDs, timestamps, permissions) in single DB. WHEN TO USE DEDICATED VECTOR DB: PINECONE — managed, $70-$500/mo, easier ops, scales to billions. WEAVIATE — self-host or cloud, hybrid search built-in. QDRANT — fastest open-source, self-host. CHROMA — local-first, simpler. MILVUS — battle-tested at billion+ scale. RECOMMENDATIONS 2026: 1. START WITH PGVECTOR for any RAG/semantic search project. 2. DOC INDEX <50M chunks — pgvector. 3. ADD vector DB IF you outgrow + need specialized features. 4. EVAL: vector DBs add operational + integration complexity. PG-vector keeps everything in one system. EXAMPLES: Supabase Vector (built on pgvector + Studio UI). Neon DB has pgvector enabled by default. AWS RDS PG, GCP Cloud SQL PG, all support. CODE PATTERN: store original text + embedding (1536-dim for text-embedding-3-small) in Postgres. Query: SELECT id, content WHERE embedding <=> $query_embedding < 0.5 ORDER BY distance LIMIT 10. Done. SIMPLER than dedicated vector DB integration.

SQLITE IN PRODUCTION 2026 — appropriate scenarios more than people think: (1) MOBILE APPS — iOS + Android default. Apple uses SQLite extensively. WhatsApp uses SQLite for message store. (2) DESKTOP APPS — Slack, VS Code, Visual Studio, Adobe, etc. all use SQLite for local storage. (3) EMBEDDED SYSTEMS — Tesla cars run SQLite. ATMs. (4) EDGE FUNCTIONS — Cloudflare D1, Turso, Fly.io use SQLite-based services for edge compute. (5) READ-HEAVY WEBSITES — SQLite on web server with daily DB rebuild can be FASTER than Postgres. Tools like Dogsheep + Datasette popularized. (6) CMS + BLOGS — Many static-site generators use SQLite. (7) CONFIG STORE — apps storing settings/state. (8) ANALYTICS LOCAL — Litestream + Litelogs. WHEN SQLITE NOT APPROPRIATE: (1) MULTI-WRITER concurrent access (>1 writer at a time). SQLite single writer at a time though WAL mode helps. (2) MULTI-NODE distributed apps (without LiteFS/Turso). (3) Large databases (>100GB though theoretically supports terabytes). (4) Need network access (SQLite is file-based; embed it in your app). (5) Sharding/horizontal partitioning needed. PERFORMANCE TRICKS 2026: WAL mode for concurrent reads + single writer. Pragma optimizations (cache_size, journal_mode, synchronous=NORMAL). Indexes critical (SQLite optimizer good). PRAGMA query_only for replicas. CLOUD-NATIVE SQLITE 2026: TURSO — managed distributed SQLite (libsql). Sync globally. Free tier for hobby. ~$30/mo for small apps. CLOUDFLARE D1 — Cloudflare-managed SQLite for Workers. Edge deployment. FLY.IO LITEFS — sync SQLite across region. Use within Fly apps. POWERSYNC — SQLite + your-cloud-of-choice sync. Mobile-first. CONS: harder to model many-to-many relations in single-file. Not ideal for "everyone writes constantly". RECOMMENDATIONS 2026: USE SQLITE for any single-server app under 100 concurrent writers. For mobile/embedded ALWAYS. For distributed, Turso/D1/LiteFS. USE POSTGRES if you outgrow + need true client-server architecture or multi-master.

CACHING OPTIONS 2026: REDIS — feature-rich, multi-data-type, persistence, pub/sub, queues. License changed 2024 to RSALv2/SSPL (no longer purely OSS). Most-deployed cache. Connections: ~10k. Cluster mode for scale. MEMCACHED — pure RAM cache. No persistence. Multi-key get fast. Threaded (Redis was single-threaded historically). Simpler. Apache 2 OSS. Works well for sessions + simple key-value. VALKEY — Redis fork (April 2024) by AWS + Google + Oracle + others, Apache 2 license. API-compatible with Redis. Avoiding RSALv2 license. Same performance. KEYDB — older Redis fork (2021), multi-threaded, Apache 2. Now part of Snap. KEYWORDS / DICESDB — newer alternatives. WHEN TO USE WHICH: REDIS — feature-rich + need data structures (sorted sets, streams, modules). Most-used. PRO: ecosystem, knowledge availability. CON: license. MEMCACHED — pure caching, simple key-value, multi-threaded reads. PRO: simple, Apache 2. CON: no persistence, no rich data types. VALKEY — Redis API but Apache 2 license. CHOOSE if license matters to your org. Same code, same performance, OSS-friendly. AWS ElastiCache supports both Redis + Valkey. KEYDB — multi-threaded Redis. Niche. 2026 RECOMMENDATIONS: NEW PROJECTS 2026 — VALKEY by default (Redis API + clean license). EXISTING REDIS — staying on Redis fine; license matters more to vendors than apps. SIMPLE SESSIONS — Memcached if minimal use. AWS — ElastiCache Valkey or Serverless Redis. HOSTING: AWS ElastiCache, Upstash (serverless Redis-compatible, $10-$50/mo for small), Redis Cloud, DigitalOcean Managed Redis. SELF-HOST: redis-server on VPS $10-50/mo. Cluster mode for HA. SECURITY: ALWAYS use AUTH password + bind to private network. Open Redis instances scanned + exploited frequently. PERFORMANCE: Redis ~100-200k ops/sec single-threaded. Valkey same. Memcached ~150k+ ops/sec multi-threaded read.

DATABASE HOSTING COSTS 2026 (entry to mid tier): MANAGED POSTGRES: SUPABASE — $25/mo Pro (500MB), $599/mo team. Includes auth + storage + edge functions. NEON — $19/mo Launch (10GB), $69/mo Scale, branching feature. Free tier generous. AWS RDS POSTGRES — $15-$200/mo small, scales up. Variable by instance. AZURE DATABASE FOR POSTGRES — $20-$300/mo. GCP CLOUD SQL POSTGRES — $30-$300/mo. DIGITALOCEAN MANAGED POSTGRES — $15-$120/mo. RAILWAY — $20+/mo. HEROKU POSTGRES — $9-$200/mo. CRUNCHY DATA — premium PG, $30-$500/mo. MANAGED MYSQL: AWS RDS MYSQL — $15-$200/mo. PLANETSCALE — $39/mo Hobby, $599/mo Pro (Vitess-based, scales). DIGITALOCEAN MYSQL — $15-$120/mo. MANAGED MONGODB: ATLAS M0 — FREE (512MB shared, dev only). M10 — $57/mo (10GB dedicated). M20 — $114/mo (20GB). REDIS-COMPATIBLE: UPSTASH — serverless, $0-$50/mo for small projects. AWS ELASTICACHE — $30-$200/mo. REDIS CLOUD — $7-$100/mo entry. CLOUDFLARE D1 — pay-per-request, ~$5/M reads, very cheap for small apps. SQLite-based. TURSO — distributed SQLite, $0-$30/mo for hobby + small apps. SQLITE / EMBEDDED — FREE (no hosting beyond your server). VECTOR DBS: PINECONE — $70/mo Standard, $700/mo Pro. WEAVIATE Cloud — $25/mo Sandbox. QDRANT Cloud — $25/mo Starter. DATA WAREHOUSE: SNOWFLAKE — $1-$5/credit, ~$200-$5,000/mo small. BIGQUERY — $5/TB scanned + storage. DATABRICKS — $0.20-$0.55/DBU. OPTIMAL STARTUP STACK 2026: APP — POSTGRES via Neon ($19/mo) OR Supabase ($25/mo) OR self-host on $5/mo VPS ($60/yr). CACHE — Upstash Redis ($0-$10/mo). VECTORS — pgvector inside same Postgres ($0). ANALYTICS — start with main Postgres, BigQuery if outgrown ($5/TB). AVOID INITIAL: separate vector DB ($70/mo waste), separate analytics DB ($200/mo waste), Cassandra ($50/mo+ overkill). TOTAL COST FOR EARLY STARTUP: $30-50/mo total databases including hosting. SCALES TO ~10k users typical.

DISTRIBUTED SQL 2026 — NewSQL category combines SQL + horizontal scale: COCKROACHDB — Postgres-wire compatible. Self-healing. Multi-region with low write latency. License BSL/CCL (commercial requires license). $50-$500/mo cloud + self-host. USED BY: Lush, DoorDash, Netflix (parts), JPMorgan. STRENGTH: simple ops, automatic resharding. WEAKNESS: more expensive than vanilla PG. YUGABYTEDB — also Postgres-compatible. Apache 2 license (cleaner OSS). Strong consistency or eventual. Used by: Comcast, Bank of America. STRENGTH: pure OSS, similar features to CRDB. WEAKNESS: smaller community than CRDB. GOOGLE CLOUD SPANNER — proprietary GCP. Globally distributed SQL. Strong consistency at scale. EXPENSIVE ($1000+/mo small). Used by: Google internally + customers. AWS AURORA — multi-AZ Postgres/MySQL. NOT distributed SQL strictly. Single-region with read replicas. Cheaper than Spanner, less global. SUPABASE / NEON — Postgres + branching but not "distributed SQL" per se. PLANETSCALE — Vitess + MySQL. Distributed reads, single-master writes. Multi-region reads. WHEN TO USE DISTRIBUTED SQL 2026: (1) Multi-region app needs LOW write latency in multiple regions. (2) Need strict ACID at scale (>100k QPS). (3) Want SQL but vertical scale exhausted. (4) Geographic compliance — data residency in multiple regions (GDPR + similar). NOT NEEDED FOR: 90% of apps under 100k DAU. Vanilla Postgres + read replicas + caching layer = sufficient. Don't over-engineer. RECOMMENDATIONS 2026: BOOTSTRAP / EARLY STAGE — Vanilla Postgres (Supabase/Neon). MULTI-REGION SAAS at $1M+ ARR — CockroachDB or YugabyteDB. ENTERPRISE GLOBAL — Spanner if budget allows. AVOID: starting with distributed SQL "just in case". 10x complexity vs Postgres. Migrate when you actually need it.