Best Open Source Database Systems
Open source databases grouped by use case: PostgreSQL, MySQL, MariaDB, SQLite, MongoDB, Redis and Valkey, ClickHouse, DuckDB and Neo4j, with accurate license notes including SSPL.
People choose databases like they choose religions, so let me skip the theology and group them by job. Transactional databases handle your core reads and writes. Analytical databases answer big questions over lots of rows. Embedded databases live inside your app. Caches and search are their own categories. Pick the job first, then argue about the tool.
| Database | Best for | License |
|---|---|---|
| PostgreSQL | Default transactional database | PostgreSQL License |
| MySQL / MariaDB | Legacy teams, managed providers | GPLv2 |
| SQLite | Local, embedded, single-file storage | Public domain |
| MongoDB | Flexible documents, JSON-shaped data | SSPL 1.0 |
| Redis / Valkey | Cache, queues, counters | BSD / RSAL-SSPL |
| ClickHouse | Columnar analytics at scale | Apache 2.0 |
| DuckDB | Analytics inside your app | MIT |
| Neo4j | Graphs and relationships | GPLv3 |
Transactional
PostgreSQL is the boring, correct choice for most new projects. The PostgreSQL license is permissive, the feature set is enormous, JSONB covers most "noSQL" needs, and full-text search handles basic search queries. It will not be the fastest at any one thing, and it will be the least wrong at everything. If you have no strong reason otherwise, start here.
MySQL and MariaDB are the same family. MySQL is GPLv2 under Oracle, available with commercial licensing, and everywhere in managed hosting. MariaDB is the community fork, also GPLv2, and a drop-in replacement that kept the original developers. The honest difference for most teams is ecosystem and providers, not features. Choose MariaDB for community momentum or MySQL when your cloud provider makes it the path of least resistance.
MongoDB is the document store, and its license is the thing to remember. It is SSPL 1.0, which is not OSI-approved open source: you can read and modify the code, but offering MongoDB as a managed service under SSPL has serious source-sharing obligations, which is why every cloud provider runs its own fork or compatible engine. Use it when JSON-shaped, schema-flexible documents are genuinely the right model. It is not a database you should default to.
Cache and key-value
Redis was the canonical answer until the licensing change: 7.2 and earlier are BSD-3, the 7.4 Community Edition moved to RSALv2/SSPLv1, and Redis 8 added AGPLv3 as a third option. The practical consequence is that Valkey, the Linux Foundation fork under BSD-3, is now the safe open source choice for cache, queues, and counters, and most cloud providers back it. If you need the latest Redis features, read the license terms carefully. For plain caching, Valkey is the sane default.
Analytical
ClickHouse is the heavyweight analytical engine, Apache 2.0, built for columnar queries over billions of rows. It shines for event data, observability, and any "select over everything we have ever logged" workload, and it is the common backend for self-hosted analytics. It wants real servers and real RAM.
DuckDB is the embedded analytical answer, MIT licensed, a columnar database that runs inside your process and can query Parquet and CSV files directly. For an analyst, a script, or an app that needs local analytical speed, it replaces a whole data stack. It is not designed for many concurrent users writing to it, so treat it as a powerful engine, not a server.
Embedded
SQLite is in the public domain, which settles most license questions, and it is the most widely deployed database on earth by a wide margin. For local data, desktop apps, edge devices, and anything that fits in one file, it is the correct answer and nothing else comes close. Its limits, no distributed writes, one writer at a time, are well understood and rarely the actual bottleneck.
Graph
Neo4j community edition is GPLv3, which matters because the product is under commercial licensing for production and enterprise use. Its real strength is relationship-heavy queries, fraud networks, knowledge graphs, recommendations, that a SQL join pyramid handles painfully. For anything where the graph is the point, nothing else on this list works as well. For everything else, PostgreSQL with a few recursive CTEs gets you further than you expect.
Search
Full-text search deserves its own line. PostgreSQL's built-in FTS and the trigram indexes handle small to medium search workloads with zero extra infrastructure. When you outgrow that, look at dedicated engines, and read their licenses too: Elasticsearch moved to SSPL, while OpenSearch and Meilisearch remain permissively licensed alternatives. The pattern across this list is consistent. The database is rarely the real bottleneck, but the license is a decision you make once and live with for a decade.