Open Source Database
A database is the one piece of your stack you cannot casually swap, because the data outlives every application written against it and the schema quietly becomes the contract everything else depends on. That is why the engine you choose today shapes your options for years. The open source databases here keep the storage format and query layer in the open, whether they are relational, columnar, time-series, key-value, vector, or graph, so migrating, replicating, or auditing your own data never waits on a vendor's permission or pricing. Owning the engine also means you can run it next to your application, read its on-disk format, and back it up on your own schedule rather than a service's.
Elasticsearch
Distributed RESTful search and analytics engine with vector search and near real-time indexing
NocoDB
Self-hostable no-code platform that turns any database into a spreadsheet interface
Meilisearch
Open-source search engine API for hybrid full-text and semantic search in apps and websites
ClickHouse
Open-source column-oriented OLAP database for real-time analytical reports with SQL
Milvus
Cloud-native vector database for scalable ANN search, hybrid search, and real-time updates
TiDB
Open-source distributed SQL database with ACID transactions, HTAP, MySQL compatibility, and vector search
DuckDB
In-process SQL OLAP database for analytical queries with CLI, language clients, and direct CSV and Parquet reads
Directus
Wraps any SQL database in instant REST and GraphQL APIs, a no-code admin app, and auth
Qdrant
Vector database and search engine for semantic search with payload filtering, hybrid search, and distributed deployment
Our picks
This category spans very different jobs, so treat these as starting points by workload rather than a ranking.
General-purpose relational default: PostgreSQL PostgreSQL handles structured data with transactions, foreign keys, triggers, and user-defined types and functions, under a permissive license that keeps it free to embed anywhere. Because its types and functions are user-extensible, you can model domain-specific data in the database instead of around it, which is why so much else here builds on top of it.
Distributed SQL when one node is not enough: CockroachDB CockroachDB keeps strongly consistent ACID transactions while scaling horizontally across a cluster, and it is designed to survive disk, machine, rack, and datacenter failures without manual intervention. It speaks the PostgreSQL wire protocol, so existing Postgres drivers can connect from many languages with little change.
Vector search for AI features: Qdrant Qdrant stores points as vectors plus JSON payloads, so a single query can combine semantic similarity with full-text, numeric, geo, and boolean filters. It runs as a container, on its managed cloud, or embedded in your process with Qdrant Edge, and hybrid search with RRF and DBSF fusion covers retrieval without a second system.
Analytics without running a server: DuckDB DuckDB runs in-process rather than as a separate server and queries CSV and Parquet files directly from the FROM clause, which suits local analysis and embedding in applications. Its SQL dialect includes window functions, nested subqueries, and complex types, with clients for Python, R, Java, and Wasm under the MIT license.
Matching the engine to the workload
The word database covers far more ground here than a shortlist assumes, and naming the shape of your data first rules out most of the list before you compare a single feature. A relational engine like PostgreSQL or MariaDB answers questions with joins, constraints, and transactions. A columnar OLAP store such as DuckDB or ClickHouse is built to scan billions of rows for a report and would be miserable as an application's primary store. A time-series engine like TimescaleDB or QuestDB expects append-heavy, time-ordered data, while vector databases like Qdrant, Milvus, and Weaviate exist to find nearest neighbors for semantic search and retrieval, not to run your billing.
The next fork is how much the database must guarantee when something breaks. Engines built for strong consistency, from single-node PostgreSQL to the distributed SQL of CockroachDB, TiDB, and YugabyteDB, give you ACID transactions and predictable recovery, which is what billing, inventory, and permissions need. Systems that favor availability and write throughput, like Apache Cassandra or a Redis-compatible store such as Valkey or Dragonfly, are excellent for caches, feeds, and telemetry but push conflict handling back into your application code. Read the replication and transaction docs closely, because a benchmark number tells you nothing about how an engine behaves when a node dies mid-write.
Whatever you shortlist, rehearse the operational parts before you commit. Restore a real backup into a clean machine and time it, run a schema migration, and test failover on data that resembles production. The exit path matters just as much: standard dump formats, a widely spoken wire protocol, and solid drivers in your language decide how trapped you are later. PostgreSQL's protocol is the most common here, which is why extensions like Citus and Apache AGE build on it rather than reinventing a database.
Related categories
Frequently asked questions
Do I really need a specialized database, or can PostgreSQL handle most of this?+
PostgreSQL covers a surprising range on its own, and much of this list extends it rather than replacing it. Citus shards it across a cluster, TimescaleDB adds time-series storage, and Apache AGE adds a graph model with openCypher, all while keeping standard SQL. Reach for a purpose-built engine when one dimension dominates, such as billions of vectors, millions of events per second, or graph traversals many hops deep, and not before.
What is the difference between a vector database and a search engine on this list?+
A vector database like Qdrant, Milvus, Chroma, or Weaviate stores embeddings and finds nearest neighbors, which powers semantic search, recommendations, and retrieval-augmented generation. Full-text engines such as Meilisearch or Typesense match keywords, facets, and filters with ranking you can explain. Several tools blur the line: Weaviate and Manticore Search run hybrid queries that combine vector similarity with keyword search in a single request.
Which of these can reuse my existing PostgreSQL or MySQL drivers?+
CockroachDB and YugabyteDB speak the PostgreSQL wire protocol, so Postgres client drivers connect with little change, and TiDB and MariaDB target MySQL compatibility for the same reason. Citus and TimescaleDB are literally PostgreSQL extensions, so existing tooling keeps working. For Redis clients, Valkey, KeyDB, and Dragonfly all keep the Redis protocol, which lets applications point at them without code changes.
Are the spreadsheet-style tools here real databases?+
NocoDB, Teable, Baserow, and Grist are interfaces on top of a real database rather than storage engines themselves. Teable and NocoDB sit on Postgres, Grist on a SQLite-based file, and Baserow on PostgreSQL. Directus works the same way, wrapping an existing SQL database in REST and GraphQL APIs. They are excellent for turning a database into shared, editable views, but the durability and query power still come from the SQL engine underneath.
When is a graph database worth it over joins in a relational database?+
Choose a graph engine when relationships are the main thing you query, such as friend-of-a-friend paths, fraud rings, recommendations, or knowledge graphs, and traversals run many hops deep where SQL joins get slow and awkward. Neo4j uses Cypher, NebulaGraph and Apache HugeGraph offer OpenCypher-compatible access, and JanusGraph uses Gremlin. If you only occasionally follow relationships, Apache AGE adds graph queries to PostgreSQL without a separate system.
Why pick a Redis-compatible store like Valkey instead of Redis itself?+
The three Redis-compatible options here exist for licensing or performance reasons. Valkey was forked from Redis right before Redis moved to source-available licenses, so it keeps an open community path under the Linux Foundation. KeyDB adds multithreading and active replication while staying protocol-compatible, and Dragonfly reimplements the Redis and Memcached APIs with a shared-nothing architecture aimed at higher throughput on a single machine.
Several of these use source-available licenses instead of Apache or MIT. What changes?+
Engines like CockroachDB, Dragonfly, NocoDB, and Directus ship under source-available or business-style licenses, which let you read and self-host the code but restrict offering it as a competing managed service. For most internal use that is not a problem, but if you plan to resell hosting or need a strictly open license, check the exact terms. PostgreSQL, MariaDB, DuckDB, and the Apache-licensed engines here avoid the question entirely.