How to Choose a Database in 2026: Eight Options Compared by Use Case

PostgreSQL, MySQL, SQLite, MongoDB, Redis, Cassandra, DynamoDB and ClickHouse compared by use case, with facts checked as of October 2026.

Anshu Pathak
•
11 min read
How to Choose a Database in 2026: Eight Options Compared by Use Case

Facts checked as of October 2, 2026.

No database is the best at everything. Each one makes trade-offs, and the right pick depends on what your application will actually do with its data.

This post compares eight databases: PostgreSQL, MySQL, SQLite, MongoDB, Redis (and its fork Valkey), Apache Cassandra, Amazon DynamoDB and ClickHouse. For each one you get what it is good at, where it hurts, and what changed recently.

Version numbers, dates, licenses and limits below were checked in early October 2026, mostly against project documentation, release notes and lifecycle trackers. A few points rest on secondary sources such as Wikipedia, vendor blogs or news coverage, and the text flags those. It also says so where sources disagreed, or where a point is a judgment rather than a fact.

The short version

Database

Best fit

Main trade-off

PostgreSQL

General-purpose system of record, complex queries, extensions

Every major upgrade is a planned migration

MySQL

Classic transactional web applications

No native vector search yet, and some community worry about Oracle's pace

SQLite

Local or embedded storage inside one application

One writer at a time, one machine

MongoDB

Data that naturally fits self-contained documents

SSPL license, 16 MB document cap

Redis / Valkey

Caching, rate limiting, queues, fast data structures

In-memory first, and a licensing split between the two projects

Cassandra

Write-heavy, always-on, multi-datacenter workloads

You design tables around queries and denormalize

DynamoDB

Key-based access at scale, with little to operate, on AWS

AWS only, 400 KB item limit, limited ad hoc querying

ClickHouse

Analytics over large tables

Built for analysis, not for transactional workloads

A quick way to narrow it down

flowchart TD
  A["What is the main job?"] --> B{"Analytics over large datasets?"}
  B -->|Yes| CH["ClickHouse"]
  B -->|No| C{"Need an in-memory cache or fast data structures?"}
  C -->|Yes| R["Redis or Valkey"]
  C -->|No| D{"Embedded in one app on one machine?"}
  D -->|Yes| S["SQLite"]
  D -->|No| E{"Known key-based access patterns at very large scale?"}
  E -->|"Yes, on AWS"| DDB["DynamoDB"]
  E -->|"Yes, self-hosted, multi-datacenter"| CAS["Cassandra"]
  E -->|No| F{"What shape is the data?"}
  F -->|"Relational, with joins and constraints"| PG["PostgreSQL or MySQL"]
  F -->|"Self-contained documents"| M["MongoDB"]

This is a starting point, not a verdict. Most real systems end up with more than one database, which the end of this post covers.

PostgreSQL

PostgreSQL is a relational database released under the PostgreSQL License, a permissive license. The current stable line is 18. Version 18.6 shipped on August 13, 2026, and under the project's five-year policy the final 18 release is due on November 14, 2030.

PostgreSQL 18 was mostly about speed and day-to-day comfort:

  • A new asynchronous I/O subsystem, which helps sequential scans, bitmap heap scans and vacuum.

  • Skip scan for multicolumn B-tree indexes, so queries that leave out the leading column can still use the index in more cases.

  • uuidv7(), which generates timestamp-ordered UUIDs that index better than random ones.

  • Virtual generated columns, computed at read time, now the default for generated columns.

  • OAuth 2.0 authentication.

  • Page checksums on by default for new clusters.

  • Planner statistics that survive a major-version upgrade, so performance recovers faster afterward.

Where it fits. PostgreSQL is a safe default for the system of record behind most applications: orders, accounts, inventory, anything where constraints and transactions matter.

It also stretches further than most relational databases because of extensions. PostGIS adds geographic types and queries. pgvector adds vector similarity search with HNSW and IVFFlat indexes, which can cover smaller AI-feature needs without a separate vector database.

Where it hurts. Moving to a new major version is a deliberate migration. The release notes for 19 say a dump and restore, pg_upgrade or logical replication is required to move from any earlier release.

What is coming. PostgreSQL 19 is still in beta. Beta 4 shipped on September 24, 2026. On September 28 the release team scheduled release candidate 1 for October 15 and general availability for October 29, unless significant issues turn up during the release candidate period.

Several planned features were pulled along the way. SQL/PGQ graph queries, once expected to headline the release, were removed. If you read an early-beta article about 19, check it against the current release notes before relying on it.

MySQL

MySQL ships on two tracks. LTS releases are meant for production and get five years of premier support plus three years of extended support. Innovation releases arrive more often and are supported only until the next release.

Where things stand:

  • MySQL 9.7 (LTS) reached general availability on April 21, 2026. Premier support runs to April 2031 and extended support to April 2034.

  • MySQL 8.4 (LTS) has premier support to April 2029 and extended support to April 2032.

  • MySQL 8.0 reached end of life in April 2026. Version 8.0.46 was the last release, so anyone still on 8.0 is running without security patches.

MySQL 9.7 moved five components from Enterprise to Community Edition. Four are replication components (applier metrics, group replication flow control statistics, the group replication resource manager, and primary election visibility). The fifth is a telemetry component that can send metrics and traces to Prometheus and OpenTelemetry.

The Hypergraph Optimizer is also in Community now. It plans complex multi-table joins differently from the traditional optimizer, and you turn it on with the optimizer_switch setting. A guest post on Oracle's MySQL blog, written by an Altinity engineer, suggests testing it on slow queries at session scope before enabling it globally. JSON Duality Views also gained full insert, update and delete support in Community.

Where it fits. Classic transactional web applications, especially ones already built around MySQL and its replication tooling.

Where it hurts. Native vector search is not generally available in 9.7. The same guest post says Oracle appears to be building toward it across the 9.x Innovation releases, but it is not usable yet.

There is also a governance question. InfoQ reported on a repository analysis that showed declining development activity and a shrinking contributor base, followed by Oracle layoffs, and noted that tracking forks are underway. That is worth weighing for a ten-year decision, though it is not a reason to panic about a database that just shipped a new LTS.

One operational warning from the 9.7 launch: a bug in the mysql-community.repo update (MySQL Bug #120315) silently disabled the 8.4 LTS repository and enabled 9.7 instead, so routine package updates could switch the major version a server follows. Pin the series you intend to run.

SQLite

SQLite is a C library that runs inside your application. There is no server process. Its source code is in the public domain, and its website calls it the most used database engine in the world, built into all mobile phones and most computers.

The latest release is 3.53.4 (July 24, 2026). Only the latest release is supported, though the developers have pledged to support SQLite through the year 2050.

If you use WAL mode, stay current. The 3.53.1 release notes list a fix for a WAL-reset database corruption bug.

Where it fits. App-local storage on phones and desktops, test databases, command-line tools, and small services where one process on one machine is the whole story. There is nothing to install, secure or keep running.

Where it hurts. SQLite allows only one writer at a time. In write-ahead log (WAL) mode, readers and a writer no longer block each other, but two simultaneous writers still queue, and the second one can get an SQLITE_BUSY error. WAL mode also uses shared memory, so all readers must be on the same machine.

That makes SQLite a poor fit for many application servers writing to one shared database over a network.

MongoDB

MongoDB is a document database. It moved from the AGPL to the Server Side Public License (SSPL) starting with release 4.0.4 on November 8, 2018. The SSPL adds a condition for anyone offering MongoDB as a service, so check it with your legal team if you plan to resell or host it.

Multi-document ACID transactions have been available since MongoDB 4.0 in June 2018, so "MongoDB has no transactions" is out of date.

The current minor release is 8.3 (May 2026), with 8.3.11 released on September 11, 2026. Version 8.0 is supported until October 31, 2029. Recent 8.3 patch releases have carried security fixes, so keep patching.

MongoDB also ships search. The engine behind MongoDB Search and Vector Search, called mongot, was released in public preview under the SSPL in January 2026, extending those features to self-managed Community and Enterprise deployments.

Where it fits. Data that is naturally one self-contained document: product catalogs, content, user profiles, configuration. If you usually read and write an entity as a whole and rarely join across entities, documents are convenient.

Where it hurts. The maximum BSON document is 16 MB, and MongoDB supports at most 100 levels of nesting. Larger files go through GridFS. If your data is highly relational, you will end up re-creating joins in application code.

Redis and Valkey

These two share a history, so treat them together.

Redis was released under the permissive BSD license for years. In March 2024 it moved to the Redis Source Available License v2 and the SSPL. The Linux Foundation then forked the last BSD release, Redis 7.2.4, as Valkey. In May 2025, Redis 8.0 added the OSI-approved AGPLv3 as a third license option.

Redis today. The current line is Redis 8.10 (general availability in July 2026). Redis 8.0 folded the formerly separate RediSearch, RedisJSON, RedisTimeSeries and RedisBloom modules into the core product and added vector sets. Recent releases added:

  • Redis 8.8 (May 2026): an Array data structure, INCREX (a windowed counter for rate limiting) and XNACK for streams.

  • Redis 8.10 (July 2026): compact hashes, a hash encoding that saves memory by storing field names once for keys that share a schema.

Recent patch releases carried security fixes. Redis 8.8.1 fixed crafted RESTORE payloads in RedisBloom and TDigest that could lead to remote code execution, and 8.10.1 fixed a malicious RDB payload that could cause memory corruption and possibly remote code execution. Patch promptly and never expose an instance to the open internet.

Valkey today. Valkey keeps the BSD license and is governed by the Linux Foundation. Version 9.1 arrived on May 19, 2026, with 9.1.1 following on July 21. It also introduced Valkey Admin, an open-source visual cluster management tool, and database-level ACLs for multi-tenant isolation. Search lives in a separate BSD-licensed module, Valkey Search, which reached version 1.2 alongside 9.1 and covers full-text, numeric, tag and vector queries. Valkey is reportedly the default on AWS ElastiCache and MemoryDB.

Where they fit. Caching is the classic job: a fast layer in front of a slower database. The same data structures cover sessions, rate limiting, pub/sub and stream-based queues.

Which one. If your legal team is wary of AGPL's copyleft terms, Valkey's BSD license is the simpler path. The main difference in packaging is that Redis 8 builds JSON, search, time series and vector sets into the core, while Valkey keeps search as an add-on module. Both speak the same protocol, but check feature support before you assume a drop-in swap.

Where they hurt. Memory is expensive compared with disk. Treat either one as a fast layer in front of a durable store unless you have configured and tested persistence for your needs. That last part is advice rather than a documented limit.

Apache Cassandra

Cassandra is a wide-column database under the Apache 2.0 license. Its defining design choice is that it has no leader. Every node is equal, any node can serve reads and writes, and data is spread across nodes by consistent hashing. That removes any single point of failure.

Consistency is tunable per operation. You choose how many replicas must acknowledge a read or write, which lets you trade strictness for availability and speed on a case-by-case basis. For multi-datacenter deployments, the NetworkTopologyStrategy replication option controls how replicas are placed across regions.

Cassandra 5.0 (September 2024) is the current general-availability line. It added Storage Attached Indexes and a vector data type. The latest 5.0 patch listed on Maven Central is 5.0.9 (July 28, 2026), and 6.0 is in alpha.

Where it fits. Write-heavy workloads, always-on services, and data replicated across several datacenters. You can add nodes to a running cluster without taking it down.

Where it hurts. You model tables around the queries you will run, and you denormalize. If you do not know your access patterns in advance, Cassandra will fight you. It is also more work to operate than a managed service.

Amazon DynamoDB

DynamoDB is a fully managed NoSQL service from AWS. There is no version to track and no server to patch. You choose between on-demand and provisioned capacity modes.

Capacity is measured in request units. One read request unit is one strongly consistent read of an item up to 4 KB, or two eventually consistent reads. One write request unit is one write of an item up to 1 KB. Transactional reads and writes cost twice as much.

The limits shape how you design for it:

  • The maximum item size is 400 KB, and attribute names count toward it.

  • Queries work mainly on the primary key and sort key, so access patterns need to be designed up front.

  • Transactions are supported, but not across Regions in global tables.

  • For a table with local secondary indexes, an item collection cannot exceed 10 GB.

Where it fits. Serverless backends, session and cart storage, and other workloads with predictable key-based access where you do not want to run a database cluster. It scales without much tuning, and you pay for what you use.

Where it hurts. It runs only on AWS, so moving off it later means rewriting your data layer. Because queries revolve around the primary key and sort key, ad hoc queries and reporting are awkward.

ClickHouse

ClickHouse is a column-oriented database built for online analytical processing (OLAP). It is written in C++, ships as a single binary, and uses the Apache 2.0 license. The core engine, including clustering, is covered by that license.

Releases use calendar versioning, such as 26.8, with a new release roughly every month. Twice a year, typically in March and August, a release is designated long-term support. The 26.3 release was an LTS, and 26.8, also an LTS, shipped at the start of September 2026.

Where it fits. Dashboards, event and log analytics, and real-time reports over very large tables, queried with SQL. It also has an embedded variant, chDB, which runs the engine in-process.

Where it hurts. It is not a transactional database, so do not use it as your system of record. Self-hosting a cluster at scale is not trivial, and it requires running ClickHouse Keeper for coordination. ClickHouse also offers a managed service, ClickHouse Cloud, if you would rather not run it yourself.

Licenses at a glance

License terms matter more than they used to, so here they are in one place.

Database

License

PostgreSQL

PostgreSQL License (permissive)

MySQL

GPLv2 for Community Edition, or a commercial license from Oracle

SQLite

Public domain

Cassandra

Apache 2.0

ClickHouse

Apache 2.0

Valkey

BSD

Redis

Redis Source Available License v2, SSPL or AGPLv3 (your choice)

MongoDB

SSPL

DynamoDB

Proprietary managed service

Putting them together

Most production systems use several of these at once. Two patterns come up constantly, though they are common practice rather than rules.

A relational database plus a cache. PostgreSQL or MySQL holds the data, and Redis or Valkey absorbs repeated reads and handles things like rate limits.

A relational database plus an analytics engine. The transactional database serves the application, and a copy of the data flows into ClickHouse for reporting, so heavy queries never touch the live system.

A sensible default for a new application is PostgreSQL, because it covers the widest range of needs and leaves room to add a specialist later. That is an opinion, not a measurement. If you already know your workload is huge key-value traffic, global writes or pure analytics, start with the specialist instead.

What this post leaves out

Several categories were skipped to keep the comparison focused: graph databases, dedicated search engines, standalone vector databases, MariaDB, and distributed SQL systems. Each deserves its own comparison.

Sources checked

Version numbers move fast. Check each project's release page before you pin a version in production.


Comments (0)

Join the discussion by logging into your account.

No comments yet. Be the first to comment!

Anshu Pathak

Passionate developer sharing knowledge about modern web technologies and best practices.

Subscribe to Anshu Pathak's Newsletter

Direct email dispatches when new stories are published. Zero algorithms.