★ 7,851C++GPL-2.0updated Jul 2026
best for teams who want a MySQL-compatible server with a community-run roadmap instead of Oracle's
MariaDB is what you reach for when you want MySQL's ubiquity without MySQL's new owner. The storage engine plugin system is the real advantage — swap in RocksDB or Spider without recompiling — and system-versioned temporal tables give you audit history without hand-rolled triggers, a feature MySQL copied years later.
The 'drop-in replacement' claim on the README is the thing to be skeptical of. Fifteen years of divergence means replication formats, JSON handling, and auth plugins don't line up cleanly with MySQL 8.x anymore, so migrating either direction needs real testing, not a config swap. If you need distributed, Galera gets you there, but it has hard limits on DDL and large transactions that a team used to normal replication will trip over.
Compared to CockroachDB and TiDB, which are upfront about being distributed systems with a real learning curve, MariaDB still markets itself as the simple MySQL swap-in it stopped being years ago.
Our full take →GitHub ↗
★ 32,576GoNOASSERTIONupdated Oct 2026
best for apps that need Postgres-compatible SQL with automatic multi-region failover
CockroachDB is the pick if you want Postgres's SQL and drivers but need the database itself to survive a region going down. The architecture writeups on serializable isolation and HLC clocks aren't marketing — they explain real tradeoffs, and Postgres wire compatibility means your existing ORM mostly just works.
The thing to check before committing: the license changed to the CockroachDB Software License in late 2024, so this isn't a fully open-source project anymore for every use case, especially if you'd ever offer it as a service to others. The build is also heavy — Bazel, a sprawling monorepo — nothing like building a simple Go project from source.
Next to TiDB, which stayed Apache-licensed and splits into more separate components, CockroachDB trades license freedom for a tighter single-binary-per-node model. Both are real distributed systems; neither is a casual Postgres replacement for a side project.
Our full take →GitHub ↗
★ 40,661GoApache-2.0updated Oct 2026
best for running live transactions and analytics off the same cluster without a separate ETL pipeline
TiDB is for a team that's outgrown single-node MySQL and wants transactions and analytics off the same cluster, not a Spark pipeline bolted on afterward. Separating TiKV (storage) from TiDB (compute) lets you scale each independently, and Raft-based replication with geo-placement gives disaster recovery that's actually been exercised at companies like Shopee, not just described in a diagram.
What you're signing up for operationally is bigger than it looks: TiKV, PD, TiFlash, and TiDB server are four separate things to run and understand, more moving parts than CockroachDB's single binary. Some MySQL features — triggers, foreign keys, stored procedures — have had spotty support historically, so check compatibility before assuming a clean migration. The recent README pivot toward 'agentic workloads' and vector search reads like marketing layered onto a ten-year-old engine; test the vector search yourself before trusting the pitch.
If CockroachDB is the simpler single-binary distributed option, TiDB trades that simplicity for a harder separation between transactional and analytical work.
Our full take →GitHub ↗
★ 47,935C++Apache-2.0updated Jun 2026
best for crunching billions of rows with sub-second analytical SQL queries
ClickHouse is for the moment Postgres or MySQL stop being able to GROUP BY your data fast enough. Columnar storage with SIMD vectorization makes aggregation over ten billion rows a sub-second query, not a batch job you schedule overnight, and it ships as a single binary with no JVM to babysit.
The catch is that it's built for writing once and reading often. UPDATE and DELETE rewrite entire data parts, so anything with frequent row-level changes will be miserable here. Pick your ORDER BY key carefully when you create a table — getting it wrong is a mistake you can't cheaply undo once you're at scale — and the default memory settings will OOM under a real workload until you tune them.
Where DuckDB is the same analytical idea shrunk down to one process and one file, ClickHouse is the version built to serve many queries from many clients at once. If you're the only one running the queries, that's a reason to look at DuckDB instead.
Our full take →GitHub ↗
★ 38,766C++MITupdated Jun 2026
best for querying a CSV or parquet file with real SQL and no server to install
DuckDB is for querying a Parquet file or a folder of CSVs with real SQL, right now, without standing up a server. Reading straight from Parquet, CSV, or S3 with no import step is the whole pitch, and the SQL dialect — FROM-first queries, correlated subqueries that actually work — makes it more pleasant to use than ClickHouse for ad hoc analysis.
It's strictly single-writer, so the moment more than one process wants to write to the same database file, you'll hit contention. The extension API isn't stable across minor versions either — the number of patches this repo carries against its own first-party extensions on every release says how often those internals break. Persistence on cloud storage is also still awkward: you can query files that live in S3, but the database file itself has to be local.
Think of it as ClickHouse's answer for a single machine instead of a cluster. If you need concurrent writers or a server other people can query, that's where ClickHouse takes over.
Our full take →GitHub ↗
★ 10,088CNOASSERTIONupdated Jul 2026
best for shipping a database inside the application binary itself
SQLite is the one you don't evaluate so much as default to — it's in every iPhone, most browsers, and more production systems than anyone can count, and the public domain license means no legal review before you ship it. The amalgamation build (one 250k-line C file) and a test suite with genuine 100% branch coverage are why it can make reliability promises no other database here even attempts.
The tradeoffs are structural, not incidental. One writer at a time is baked into the file locking, and WAL mode only ever helps reads, not that limit — people keep trying to run it as a server under concurrent writes and getting burned anyway. Contributing is also unlike any other project on this list: it's a read-only mirror, pull requests aren't accepted, and the core — particularly the query planner — is dense enough that the README itself warns it won't be easy to hack on.
If the single-writer limit is the actual blocker for your project, Turso is the newer attempt to fix exactly that problem — just know it hasn't earned SQLite's decades of proof yet.
Our full take →GitHub ↗
★ 19,142RustMITupdated Jun 2026
best for SQLite workloads that need to live at the edge or sync across devices
Turso exists because SQLite's single-writer limit eventually kills most SQLite deployments, and Turso's answer — BEGIN CONCURRENT with real MVCC, async I/O via io_uring — actually fixes that instead of working around it. Built-in vector search means small datasets don't need a separate vector database bolted on, and they're running deterministic simulation testing to catch concurrency bugs most projects never find until production.
It's a ground-up rewrite, not a fork, and COMPAT.md exists because SQLite compatibility is a moving target — subtle behavior differences will surface in production before your tests catch them. The vector search is exact, O(n), and falls apart past a few hundred thousand vectors until approximate indexing ships. It's also still beta by the team's own admission, and it's the second attempt at this idea from the same company after libSQL — libSQL is the production-ready one right now, so picking Turso means betting on the newer, less proven horse.
Against SQLite, the tradeoff is simple: you're giving up decades of proof for a real fix to the one limitation that actually matters.
Our full take →GitHub ↗
★ 17,055JavaApache-2.0updated Jun 2026
best for ingesting and querying time-series data with SQL instead of a bespoke query language
QuestDB earns its spot for one reason: time-series SQL extensions like ASOF JOIN and SAMPLE BY that solve timestamp-alignment problems other databases make you hand-code. Zero-GC Java with SIMD vectorization keeps ingestion latency predictable, and the Parquet cold-storage tier lets you query old data directly off object storage instead of running a separate import job.
High availability is enterprise-only, which means the open-source build is a single node — a hard stop for anyone who can't tolerate downtime. PGwire compatibility looks like a Postgres database from the outside, but the SQL dialect diverges enough (different schema behavior, renamed or missing functions) that treating it as one will produce surprises. The Java/C++ split codebase is also genuinely harder to build from source than most of the other picks here, needing Maven, CMake, and Rust toolchains all at once.
Compared to ClickHouse, QuestDB is the better fit specifically for time-series shaped data — anything with a timestamp and ordered joins — while ClickHouse is the broader analytical engine for everything else.
Our full take →GitHub ↗
// questions people ask
Before you choose
Is CockroachDB still open source?
Not fully. The core moved to the CockroachDB Software License in late 2024, which restricts offering it as a hosted database service to others. For internal use it behaves like open source; if you're building a product on top of it, read the license first.
ClickHouse or DuckDB for analytics?
ClickHouse if multiple people or services need to query the same large dataset concurrently — it's a server you run once and hit from everywhere. DuckDB if it's one process doing the analysis, like a script or notebook, and you'd rather not stand up infrastructure for it.
Is SQLite reliable enough for a real production app?
Yes, for anything that isn't heavy concurrent writes — it's the most tested database engine that exists, embedded in every iPhone and most browsers. The one real constraint is a single writer at a time; past that, Turso is the project trying to fix it, though it's still in beta.
What's the actual difference between CockroachDB and TiDB?
CockroachDB speaks Postgres and ships as one binary per node; TiDB speaks MySQL and splits into separate TiKV, PD, and TiFlash components, which means more pieces to run but a cleaner split between transactional and analytical work. TiDB also stays Apache-licensed, where CockroachDB does not.
We end up writing about database internals a lot in the weekly finds.dev email, usually because a release did something specific worth flagging rather than just bumping a version number.