Weigh the choice. Then pick.
Side-by-side write-ups of the tools backend engineers choose between. Each page covers the same eight or so dimensions, a short decision wizard, a benchmark with a cited source, alternatives, and explicit situational picks. No vendor framing, no taste-driven rankings, just the trade-offs that matter at scale.
Also available Handbook decision pages → When-to-shard, when-to-introduce-a-queue, how-to-estimate-cost. Decision frameworks instead of head-to-heads.Databases
The store underneath. Pick by feature depth, not popularity.
Relational engines, the one decision most teams get wrong by defaulting to whatever they already know. The comparisons here weigh feature depth, replication, ecosystem reach, and cost.
Postgres vs MySQL
Postgres has the deeper feature set and the more honest engine. MySQL has the broader ecosystem and the easier replication story. New projects without strong reasons should default to Postgres.
ReadMongoDB vs Postgres
The historical answer flipped between 2018 and 2024. Postgres with JSONB now matches Mongo on document workloads while giving you SQL, joins, and transactions for free. Pick Mongo if you need its horizontal sharding out of the box; pick Postgres for almost everything else.
ReadSQL vs NoSQL
Default to a relational database. Schemas, joins, and ACID transactions are exactly what most applications need, and Postgres alone covers an enormous range. Reach for a NoSQL store when you have a specific shape it fits better: massive write throughput, a flexible/evolving document shape, or a graph/time-series access pattern that relational engines model awkwardly.
ReadSupabase vs Neon
Both give you managed Postgres. Supabase wraps it in a full backend platform — auth, storage, realtime, auto-generated APIs, edge functions — so you can build an app without a separate backend. Neon focuses on the database itself, with serverless separation of storage and compute, instant branching, and scale-to-zero that makes per-PR database previews trivial. Pick Supabase for an all-in-one app backend; Neon when you want a best-in-class serverless Postgres under your own stack.
ReadCassandra vs Scylla
ScyllaDB is a ground-up C++ reimplementation of Cassandra that keeps CQL and the data model but replaces the JVM with a shard-per-core, thread-per-core architecture — usually delivering lower and more predictable tail latency on fewer, denser nodes. Cassandra is the mature original with the widest community, broadest ecosystem, and the safety of the Apache Foundation. Choose Scylla for raw per-node performance and tighter latency SLAs; choose Cassandra for ecosystem maturity and vendor-neutral governance.
ReadSQLite vs DuckDB
Both are in-process, zero-config, single-file databases — the difference is the workload. SQLite is a row store tuned for transactional, point-read/write OLTP: app state, mobile, edge, embedded. DuckDB is a columnar, vectorized engine tuned for analytical OLAP: scans, aggregations, joins over large tables, and querying Parquet/CSV in place. They are complements, not rivals: SQLite stores your app’s rows; DuckDB crunches your analytics.
ReadDuckDB vs ClickHouse
Both are vectorised columnar engines and both are absurdly fast on one machine. The split is the deployment model. DuckDB is a library: analytics inside your process, against files, on a laptop or a Lambda, zero servers. ClickHouse is a service: continuous ingestion, materialized rollups, and thousands of concurrent dashboard queries against a cluster that is always on. Pick the shape, not the speed.
ReadCaches
In-memory layers. Pick by data shape and persistence needs.
The thin layer between request and database. Comparisons here weigh data structures, threading, persistence, clustering, and the post-2024 license picture.
Redis vs Memcached
Redis is the default for almost every cache workload now: it has data structures, persistence, pub-sub, and clustering in the box. Memcached is the right answer when the workload is a flat key-value cache and the team values the simplest possible operational story.
ReadRedis vs Valkey
Valkey is the safe continuation for self-hosters and anyone on AWS or GCP managed caches: same engine lineage, BSD license, foundation governance. Redis is the right pick if you lean on the former Stack features — JSON, the query engine, vector sets — or you are paying Redis Ltd. for cloud or support anyway. The core protocol is still compatible; the projects are slowly growing apart.
ReadAPI protocols
How services talk. Pick by audience: internal vs public.
The wire between systems. Comparisons here weigh transport, contracts, streaming, browser support, and the tooling moat that quietly decides everything.
gRPC vs REST
gRPC fits service-to-service traffic where contracts and streaming matter. REST fits any surface a third party will touch: browsers, mobile apps, partner integrations. Most teams end up with both, gRPC internally and REST at the edge.
ReadGraphQL vs tRPC
Pick GraphQL when many clients consume the API and each wants different fields. Pick tRPC when you control both ends in a TypeScript monorepo and want types to flow without a schema layer. If neither shape fits, REST is the default and gRPC is the choice for internal services — see our gRPC vs REST page for that side of the decision.
ReadMessaging
Streams or queues. Two different shapes of problem.
Distributed event logs and traditional brokers serve overlapping but distinct workloads. The comparisons here weigh throughput, replay, routing, and operational shape.
Kafka vs RabbitMQ
Kafka is the right choice when the log is the product: high throughput, replayable history, multiple consumers reading independently. RabbitMQ wins when the work is the product: complex routing, per-message acks, low-throughput priority queues.
ReadNATS vs Kafka
Kafka when the log is the system of record: long retention, replay for downstream warehouses, the Connect and stream-processing ecosystem. NATS when you want messaging as connective tissue — request/reply, fan-out, edge-to-cloud — with persistence where you need it via JetStream, all from one small binary a two-person team can operate.
ReadFrontend
UI frameworks, build tools, runtimes. The hireability axis.
Frontend stack choices weigh ecosystem reach, bundle size, developer experience, and the long-term hiring picture. Trade-offs cut differently than infrastructure.
React vs Svelte
React is the safe default when you need to hire: the ecosystem is huge and most candidates already know it. Svelte ships less code per feature and tends to score higher on day-to-day developer happiness, which counts for more once you control who maintains it. Either one builds a great app; decide on your staffing situation, not the benchmarks.
ReadNext.js vs SvelteKit
Next.js is the safer bet when you need to hire: it rides React's gravity, has the largest ecosystem, and runs on the most deployment targets. SvelteKit asks you to learn a smaller mental model and pays you back with less code per feature and developers who tend to stick around. Pick Next.js for the hiring story; pick SvelteKit when you control who builds and maintains it.
ReadEdge
Reverse proxies and ingress. Pick by config model and ecosystem.
The front door to every system. Comparisons here weigh configuration model (dynamic discovery vs static file), raw performance, observability, and TLS automation.
Orchestration
Schedulers and platforms. Pick by team size and workload mix.
Cluster orchestrators decide where workloads run. The comparisons here weigh installation tax, ecosystem reach, workload-type breadth, and operational footprint.
Containers
Runtimes and engines. Daemon vs daemonless, root vs rootless.
The layer between your code and the kernel. Comparisons here weigh architecture (client-server vs daemonless), licensing, security defaults, and ecosystem maturity.
Infrastructure as Code
Provisioning tools. Pick by license, ecosystem, and governance.
The tool that turns your cloud config into a repository. Comparisons here weigh license terms, vendor governance, registry depth, and the operational story for shared state.
Runtimes
JavaScript and language runtimes. Pick by maturity vs speed.
Where your code actually executes. Comparisons here weigh raw speed, npm/package compatibility, built-in toolchain, and the production maturity that operational lore demands.
Languages
Backend languages. Pick by productivity, performance, and hiring math.
The language your team writes in shapes everything: hire pipeline, ecosystem reach, time-to-first-deploy, and the kinds of bugs you ship. Comparisons here weigh productivity, performance, ecosystem fit, and the operational story.
Serverless
Functions-as-a-service. Pick by latency, language support, and cloud lock-in.
Compute that lives between requests. Comparisons here weigh runtime model (isolates vs microVMs), cold-start tax, geographic distribution, language coverage, and platform integration.
Service mesh
mTLS + policy + observability for Kubernetes. Pick by power vs simplicity.
The layer that intercepts service-to-service traffic. Comparisons here weigh data-plane footprint (Envoy vs Rust micro-proxy), control-plane complexity, multi-cluster maturity, and operational tax per pod.
Search
Lucene-family engines. Pick by license, cloud, and feature pace.
Full-text and vector search engines, where one 2021 fork split the field in two. Comparisons here weigh licensing and governance, feature drift since the split, client compatibility, and managed-service alignment.
Three at once.
When the real choice is between three contenders, not two.
Snowflake vs BigQuery vs Databricks
These three blur together in marketing and stay distinct in practice. Snowflake is the easiest pure SQL warehouse, with first-class data sharing; pick it when you want analytics with minimal ops. BigQuery is the most serverless of the three, with nothing to size and deep GCP wiring; pick it when you already live on Google Cloud and want ad-hoc SQL at scale. Databricks is the lakehouse, built on Spark, Delta, and notebooks; it is strongest when data engineering and ML sit right next to analytics. Plenty of large orgs end up running two of them.
Readpgvector vs Pinecone vs Weaviate
If you already run Postgres and your scale is moderate, pgvector is the obvious start — vectors live next to your relational data, no new system to operate. Pinecone is the no-ops managed option: serverless, it scales for production RAG without you tending an index. Weaviate is the open-source middle path — self-host or use their cloud, with built-in hybrid (keyword + vector) search and vectorizer modules. The real axis is how much infrastructure you want to own.
ReadThe handbook
Decision frameworks rather than head-to-heads. When-to-shard, when-to-queue, how-to-estimate-cost — the playbook for committing to one direction.
Open the handbookThe Codex
Long-form deep dives for every system the comparisons touch. Database internals, distributed systems, networking, APIs. The full study path.
Open the CodexThe simulators
49 interactive playgrounds. CAP theorem, Raft, sharding, container layers, isolation levels — turn the knobs and watch each side behave.
Browse simulators