Databases

NocoDB63.6k★

NocoDB turns any database into an Airtable-like interface with relations, forms, API access, and automations. Connect it to your existing Postgres, MySQL, or SQLite database and you get a spreadsheet UI on top of your real data. No migration, no data lock-in. The core product is strong: grid views, gallery views, kanban boards, form builder, REST API auto-generated for every table, and role-based access control. It replaces Airtable for most use cases, and your data stays in your own database. Self-hosted is free under an AGPL-like license. NocoDB Cloud exists with a free tier (unlimited bases, 1,000 rows per base) and paid plans starting at $12/user/mo for the Team tier with more rows and advanced features. Baserow is the main open source alternative, MIT licensed, similar features, actively developed. If you're already paying for Airtable and it works, the switching cost may not be worth it unless self-hosting matters to you. The catch: the license changed from MIT to a more restrictive one. Check the current terms if you're embedding it in a commercial product. Performance can get sluggish with very large datasets (100k+ rows in a single view). The automations are basic compared to what you'd build with n8n or Zapier. And development velocity has flatlined recently.

PocketBase59.2k★

PocketBase is a single executable that gives you a database, auth, file storage, real-time subscriptions, and a REST API in about 10 seconds. Download one file, run it, and you have a full backend with an admin dashboard. No Docker, no dependencies, no configuration. Everything is free under MIT. There's no paid tier, no cloud, no enterprise version. It uses SQLite under the hood, which means it's a single file for your entire database. Backups are literally copying one file. The catch: SQLite means single-server only. You can't horizontally scale PocketBase: one server, one database file, one process. For a side project, SaaS MVP, or internal tool, that's fine. For a high-traffic production app that needs 99.99% uptime across regions, you need Supabase or a real Postgres setup. And the community is passionate but small; if you hit an edge case, you might be reading Go source code to debug it.

etcd51.9k★

Etcd is the distributed key-value store that handles that consensus. Kubernetes uses it as its brain. Every piece of cluster state lives in etcd. When people say their Kubernetes cluster is down, half the time etcd is the problem. Everything is free under Apache 2.0. CNCF graduated project. No paid tier, no enterprise edition. Maintained by contributors from Red Hat, Google, and the broader Kubernetes ecosystem. Self-hosting is the only option, and it requires understanding distributed systems. A production etcd cluster needs 3 or 5 nodes (odd numbers for quorum), fast SSDs (etcd is write-heavy), and careful monitoring. It's not a general-purpose database. It's designed for small, critical metadata. Solo developers: you don't need etcd directly. If you're running Kubernetes, it's already there. Small teams: same. Let your Kubernetes distribution manage etcd for you. Platform engineers: you need to understand etcd's health, compaction, and backup procedures because when etcd is unhappy, everything is unhappy. The catch: etcd is not a general-purpose database. It's optimized for small key-value pairs (metadata, configuration, leader election) with strong consistency. Don't store application data in it. The recommended data size limit is 8GB. If you need a distributed KV store for application data, look at Redis or DragonflyDB.

DBeaver50.7k★

DBeaver connects to virtually any database (Postgres, MySQL, MongoDB, SQLite, Oracle, Snowflake, 100+ drivers) and puts them all in one interface. It's a universal remote for databases. Apache 2.0, Java. Connects to anything with a JDBC driver, which means basically every database that exists. The Community Edition handles SQL editing with autocomplete, ER diagrams, data export/import, and a visual query builder. It's a proper desktop app, not a web tool, not a CLI. The Community Edition is fully free. DBeaver PRO (formerly Enterprise) adds NoSQL support, MongoDB/Cassandra visual editors, SSH tunneling, cloud database integration, and team collaboration. PRO is $25/user/month or $199/year. Solo developers: Community Edition covers 95% of needs. Write SQL, browse data, export CSVs, all free. Small teams: still free for most SQL databases. Pay $25/mo only if you need NoSQL visual editors or team features. Growing teams: the ERD and schema comparison tools in PRO save time at scale. The catch: it's a Java app, which means it can be memory-hungry (expect 500MB-1GB RAM). Startup is slower than lightweight alternatives. And if you mostly work with one database (just Postgres, just MySQL), a specialized tool like pgAdmin or MySQL Workbench might be snappier. DBeaver's strength is breadth, not depth in any single database.

ClickHouse48.3k★

Where Postgres might take 30 seconds to aggregate a billion-row table, ClickHouse does it in under a second. It's what powers analytics at Cloudflare, GitLab, eBay, and hundreds of other companies processing massive datasets. Self-hosting is free under Apache 2.0. You get the full database engine with no feature restrictions. ClickHouse Cloud (the managed service) starts at $0.30/GB ingested with a consumption-based model. There's a free trial but no permanent free tier. The catch: ClickHouse is an OLAP database, not a replacement for Postgres. It's terrible at point lookups, updates, and deletes, the things transactional databases do well. It's designed for append-mostly data (logs, events, analytics, time-series) that you query with aggregations. If you try to use it like Postgres, you'll hate it. If you use it for what it's built for, the speed is stunning.

TiDB40.2k★

TiDB is a distributed SQL database that speaks the MySQL protocol. Your existing MySQL queries, drivers, and tools just work, but now your data is spread across multiple nodes that scale independently. Self-hosting is free under Apache 2.0. You get the full distributed database: automatic sharding, distributed transactions, real-time analytics (via TiFlash, a columnar storage engine), and online DDL changes. It's designed to handle petabytes. TiDB Cloud (the managed service) has a free Serverless tier: 5GB storage, 50M request units/month. Paid Serverless starts at usage-based pricing. Dedicated clusters start around $600/mo. The catch: running TiDB yourself is not a weekend project. A minimum production cluster needs at least 3 TiKV nodes, 3 PD nodes, and 2 TiDB nodes, that's 8 servers minimum. The operational complexity is on par with running a CockroachDB or Vitess cluster. If you're not at the scale where a single MySQL instance is failing you, TiDB introduces complexity you don't need. The free cloud tier is great for testing, not for production workloads.

DuckDB39.0k★

DuckDB runs analytical SQL queries directly on files (CSV, Parquet, JSON) or embeds inside your application as an in-process engine. No server, no installation hassle, no configuration. It embeds inside your Python script, your Node app, or runs as a CLI. It's SQLite for analytics. SQLite handles small transactional workloads; DuckDB handles analytical queries on millions of rows. It reads Parquet, CSV, JSON, and even queries Postgres directly. The performance on analytical workloads is shocking. It routinely beats dedicated database servers because it's optimized for exactly this. MIT, adopted everywhere from Jupyter notebooks to production pipelines. The catch: it's single-machine. No clustering, no multi-node, no replication. When your data outgrows one machine's RAM + disk, you need a real data warehouse. And it's analytical-only. Don't try to use it as your app's transactional database.

SurrealDB32.5k★

SurrealDB tries to be three databases in one: documents, graphs, and relational data in a single system. It has its own SQL-like query language (SurrealQL) that supports nested objects, graph traversals, and traditional joins. The self-hosted version is free under the BSL 1.1 license (converts to Apache 2.0 after 4 years). SurrealDB Cloud is in beta with pricing starting at usage-based tiers. Self-hosting is a single binary. Download and run. Embedded mode (in-process, no server) works for development. Server mode with TiKV or FoundationDB backends for production. Setup is quick for development, moderate for production HA deployment. Solo developers: great for prototyping. One database that does everything means less infrastructure to manage. Small teams: use it for projects where your data model doesn't fit neatly into one paradigm. Growing teams: proceed with caution. SurrealDB is still maturing. The catch: SurrealDB is ambitious but young. It's pre-1.0 in maturity (despite version numbers). Performance benchmarks are improving but it doesn't match Postgres for relational queries or Neo4j for graph traversals. You're trading specialization for convenience. For production systems handling real money or real users at scale, a proven database is safer today.

CockroachDB32.2k★

It speaks PostgreSQL wire protocol, so your existing Postgres tools and drivers work with it. Go. The distributed architecture means your data lives on multiple machines simultaneously, and the database handles consistency (serializable isolation by default, which is stronger than most). Automatic sharding, automatic rebalancing, geo-partitioning for compliance. CockroachDB has a complicated licensing history. The core is now under a Business Source License (BSL). You can use it freely for most purposes, but you can't offer it as a managed service. CockroachDB Serverless has a free tier: 10 GiB storage, 50M request units/month. Self-hosting is free under BSL. Minimum production cluster: 3 nodes. On modest cloud VMs, that's $50-150/mo. The ops burden is moderate. CockroachDB handles a lot of distributed complexity for you, but you still need to monitor rebalancing, node health, and storage. Solo developers: the serverless free tier is solid for prototyping. Small teams: self-host 3 nodes or use serverless. Medium to large: this is where CockroachDB earns its keep: multi-region, zero-downtime migrations, strong consistency. The catch: single-node performance is slower than plain Postgres. The distributed overhead means simple queries pay a latency tax. If your app fits on one machine and you don't need multi-region, you're paying complexity costs for resilience you don't need yet.

Dragonfly30.8k★

Dragonfly is a Redis-compatible in-memory data store rewritten in C++ with a multi-threaded architecture. Redis runs on a single core, which is its fundamental bottleneck; Dragonfly uses every core on the box. Self-hosted under BSL-1.1, free for internal use. The headline is throughput. Dragonfly claims up to 25x on multi-core machines, and even conservative real-world tests show several times the performance of Redis on the same hardware. It also uses less memory for the same data. Migration is genuinely drop-in: point your app at Dragonfly on the same port with the same commands, and most apps work without code changes. Solo and small teams running Redis without performance pain have no reason to switch. Teams hitting Redis's single-core ceiling get a free upgrade by swapping the binary. If you'd rather not self-host, Dragonfly Cloud is the managed option, starting around $0.023/hr (roughly $17/mo for a basic instance). The catch is the license. BSL-1.1 converts to Apache 2.0 after four years, but until then you can't offer Dragonfly as a competing managed service. For internal use that does not matter. The bigger gotcha is compatibility edges: some Lua scripting and module behavior differs from Redis, so test your actual workload before you move production onto it.

RethinkDB27.0k★

RethinkDB is a database that pushes changes to your app in real time instead of making you poll for them. Write a query, subscribe to it, and every time the data changes, your app gets notified automatically. C++, community-maintained since the original company shut down in 2016. The real-time push model (called changefeeds) is the core differentiator. It's a document database (stores JSON) with a query language called ReQL that's more expressive than MongoDB's: joins, subqueries, and map-reduce built in. Fully free. No paid tier, no managed cloud offering. Self-host only. The license situation is 'Other': it's Apache 2.0 for the server with some drivers under different licenses. Self-hosting is straightforward: single binary, web admin UI included, multi-node clustering works. Ops burden is moderate: you're running a database, so backups, monitoring, and failover are on you. Solo developers building real-time apps: useful and free. Small teams: solid if changefeeds solve your core problem. Medium and up: the community-maintained status is a risk. No company backing it means no SLA, no paid support, and slower feature development. The catch: the company behind it died. The community keeps it alive but development is slow. If you need a real-time database with commercial backing, look at Supabase (Postgres + real-time) or Firebase. RethinkDB is technically impressive but betting your production stack on it requires accepting orphan-project risk.

Valkey26.3k★

Valkey is the Linux Foundation fork of Redis that stays truly open source. It's Redis, maintained by the community, with the same commands, the same data structures, and the same performance. Drop-in replacement. Written in C, with Linux Foundation backing and contributions from AWS, Google, Oracle, Ericsson, and others. Forked from Redis 7.2.4, the last open source version, it's already diverging with its own improvements: multi-threaded I/O, RDMA support, and dual-channel replication. Fully free. No paid tier from the Valkey project itself. Cloud providers (AWS ElastiCache, Google Memorystore) offer managed Valkey instances at their standard pricing. Self-hosting is trivial, same as Redis: a single binary, minimal config, runs on anything, and clustering follows the same architecture as Redis Cluster. Solo to large teams: free. Starting a new project and want an in-memory store? Valkey over Redis is the straightforward choice. Existing Redis users get an easy path too: migration is a config change. Point your client at Valkey and it works. The catch: Valkey is young as a fork. The community is large and well-funded, but the project still needs to prove it can innovate independently, not just maintain compatibility. Some Redis modules (RedisJSON, RedisSearch) are not available in Valkey. You'd need alternatives for those specific features.

Neon22.3k★

Neon gives you serverless Postgres that scales to zero when nobody's using it and branches like git. That branching is the killer feature: spin up a full copy of your database for testing or development in seconds, no storage duplication. Rust storage engine, Apache 2.0. The architecture separates compute from storage, so your database can shut down completely when idle and cold-start in under a second. That's real money saved for side projects and staging environments. Free tier: 0.5 GiB storage, 1 project, 5 compute hours/month on shared compute. Enough for a side project or small app. Launch plan: $19/mo gets 10 GiB storage, 300 compute hours, and branching. Scale plan: $69/mo with 50 GiB and 750 compute hours. Enterprise is custom. Solo developers: the free tier is generous for anything that isn't hammering the database 24/7. Small teams: the $19/mo Launch plan covers most early-stage products. Medium teams: Scale plan or evaluate self-hosting the open source version. Large teams: compare Neon pricing against RDS or self-hosted Postgres. The branching and autoscaling might justify the premium. The catch: it's still Postgres, so you get Postgres's strengths and limitations. The serverless cold starts, while fast, add latency to the first query after idle. And the open source version requires serious infrastructure knowledge to self-host. Most people will use the managed service.

turso22.0k★

Turso is a distributed SQLite-compatible database built on libSQL (their open source fork of SQLite). Your data lives at the edge, close to your users, with automatic replication across locations. The libSQL engine is free and open source under MIT. You can self-host it and get SQLite compatibility with added features: native HTTP API, built-in replication, vector search extensions, and the ability to embed it directly in your application like regular SQLite. Turso's managed platform has a free tier (500 databases, 9GB storage, 25M row reads/mo), a Scaler plan at $20/mo (10K databases, 24GB storage, 100B row reads), and a Pro plan at $85/mo with higher limits. Solo devs: the free tier is generous for side projects. Small teams: free or Scaler at $20/mo covers most apps. Growing teams: evaluate if SQLite semantics fit your workload. Large orgs: probably need Postgres. The catch: this is SQLite, not Postgres. No stored procedures, limited concurrent writes, simpler type system. If your app needs complex queries or high write throughput, you want a traditional database. Turso shines for read-heavy workloads where low latency matters: think edge applications, mobile app backends, and per-user databases. The ecosystem is newer and smaller than Postgres or even PlanetScale.

Dgraph21.7k★

Instead of joining tables in SQL, you traverse relationships directly, which is orders of magnitude faster when queries go several levels deep. Go, Apache 2.0. Uses GraphQL as its native query language (plus its own DQL). Distributed by default. Shards data automatically across nodes. ACID transactions across the cluster, which most graph databases don't offer. Fully open source, self-hosted. Dgraph Cloud existed as a managed service but the company has had a rocky history: funding issues, leadership changes, license controversies (they briefly switched to a restrictive license then reverted to Apache 2.0). The cloud offering's current status should be verified before relying on it. Self-hosting requires at minimum 3 nodes for high availability (Dgraph Zero for cluster coordination + Dgraph Alpha for data). Expect significant ops burden. This is distributed systems work. The catch: the corporate instability is the real risk. License changes, layoffs, and stalled development have shaken community trust. If you need a graph database with a stable company behind it, Neo4j is the safer bet (though it's source-available, not truly open source).

teable21.4k★

Teable is a Postgres-native Airtable alternative built for speed. The data lives in real Postgres tables, which means SQL tooling works on your data natively. Fast. Modern UI. AGPL-licensed, free to self-host. Docker deployment. Lightweight and fast to start. Because data is in Postgres directly, you can query it with any BI tool or run migrations alongside your application schema. The frontend is React-based and noticeably faster than Airtable for large datasets. Engineering-leaning teams that want spreadsheet-style data management but refuse to give up direct database access will find this compelling. The Postgres-native architecture is the core differentiator: your data is not locked in a proprietary format. The catch: AGPL licensing means modifications require disclosure if distributed. The ecosystem is young: fewer integrations, fewer third-party tools, less community documentation than Airtable or NocoDB.

Vitess21.1k★

Vitess lets you shard MySQL horizontally without rewriting your application, solving the scaling limits of a single MySQL instance. It's the system YouTube built to scale their MySQL infrastructure, now a CNCF graduated project. Apache 2.0, Go. Vitess sits between your app and MySQL, routing queries to the right shard transparently. It handles resharding (splitting data when a shard gets too big), connection pooling, and query rewriting. Your app still thinks it's talking to one MySQL database. Fully free and open source. PlanetScale built a managed Vitess cloud (now pivoted/changed), and some providers offer hosted Vitess, but the core is Apache 2.0 with no restrictions. Self-hosting is where the complexity hits. Vitess has multiple components: vtgate (query router), vttablet (MySQL manager), vtctld (control plane), and an orchestration layer. Production setup requires Kubernetes or careful manual deployment. This is not a weekend project. Solo or small teams: you almost certainly don't need this. If your MySQL fits on one big server, use that. Medium teams: consider Vitess when you're hitting genuine MySQL limits. Large teams: this is home. Vitess handles the scale that justifies the complexity. The catch: the operational complexity is significant. This is infrastructure software, not a drop-in upgrade. If you don't have a dedicated database team, the learning curve and maintenance burden will eat you. CockroachDB or PlanetScale (when available) offer distributed SQL with less operational overhead.

libSQL16.9k★

LibSQL is that fork. Created by Turso, it's a drop-in SQLite replacement with features the SQLite project won't accept because they don't take outside contributions. MIT licensed. libSQL adds HTTP/WebSocket server mode (access your database remotely), built-in replication (read replicas at the edge), vector search extensions, and encryption at rest. All while maintaining full SQLite compatibility. The engine is fully free and open source. Turso (the company) sells a managed platform built on libSQL. Free tier gives you 500 databases and 9GB storage, paid plans start at $29/mo for more. The catch: libSQL is maintained primarily by one company (Turso). If Turso's business changes direction, the fork's future is uncertain, though the MIT license means anyone can continue it. It's also younger and less battle-tested than SQLite itself, which has decades of reliability data. For production use where SQLite's limitations don't bother you, stick with the original. Use libSQL when you specifically need replication, remote access, or the extensions it adds.

Neo4j16.8k★

Neo4j is a graph database where relationships are first-class citizens, not afterthought JOINs. You query connections directly instead of stitching tables together. Neo4j stores data as nodes and relationships with properties. You query it with Cypher, a pattern-matching language that reads like ASCII art: `(person)-[:KNOWS]->(friend)`. For graph queries ("find all friends of friends who like X"), it's orders of magnitude faster than SQL. The most widely used graph database. Running since 2007. The Community Edition is free (GPL v3). Enterprise starts at $36,000/yr. AuraDB (managed cloud) has a free tier and paid tiers from $65/mo. Solo developers and small teams: the Community Edition is fully functional for graph workloads. You only need Enterprise for clustering, role-based security, and hot backups. AuraDB Free gives you a small cloud instance to prototype. The catch: the GPL v3 license on Community means you can't embed it in proprietary software without opening your source. The Enterprise license jump to $36k/yr is steep. And graph databases are the wrong tool for most workloads. If your data is tabular, Postgres is faster and simpler.

TiKV16.7k★

TiKV is a distributed key-value store built for massive scale. It's the storage engine underneath TiDB (the distributed SQL database) but works standalone as a raw key-value store with strong consistency guarantees. The important distinction: this is not a cache like Redis. TiKV is a persistent, distributed, transactional key-value database. Your data survives server failures, scales horizontally, and supports transactions across keys. It uses the Raft consensus protocol, so as long as a majority of your nodes are up, your data is safe. Apache 2.0, CNCF graduated project. Written in Rust. Fully free. The catch: you do not casually deploy TiKV. It requires at least 3 nodes for production, plus a Placement Driver (PD) cluster for scheduling. The operational complexity is significant. This is infrastructure for teams that already know distributed systems. If you just need a fast key-value store for a single server, use Redis or KeyDB. TiKV is for when "what happens if a server dies" keeps you up at night.

ScyllaDB15.6k★

ScyllaDB is a Cassandra drop-in replacement written in C++ that squeezes dramatically more performance out of the same hardware. Basically, Cassandra rebuilt from scratch by people who thought Java's garbage collector pauses were unacceptable. C++, compatible with Cassandra's CQL query language and drivers. The architecture is shard-per-core: each CPU core gets its own isolated data partition, eliminating contention. This means predictable latency even under heavy load, which Cassandra struggles with. Self-hosting the open source version is free under AGPL-3.0. ScyllaDB Cloud (managed) starts around $0.28/hour for a 3-node cluster (~$600/mo). Enterprise self-hosted licenses add support, encryption at rest, and audit logging, custom pricing. Solo or small teams: if you need Cassandra-scale throughput, self-host for free. But be honest, most projects don't need this. Medium teams: ScyllaDB shines when you're doing 100K+ ops/second and Cassandra's tail latency is hurting you. Large orgs: either self-host with enterprise license or use ScyllaDB Cloud. The catch: AGPL license means if you modify ScyllaDB and serve it to users, you must open source your changes. The Cassandra compatibility is real but not perfect; some advanced Cassandra features behave differently. And the operational knowledge required is significant. This is not a database you casually deploy.

Memcached14.2k★

It's a cache. That's all it does, and it does it well. Memcached is dead simple: key-value store, everything in RAM, no persistence. You set a key, get a key, delete a key. It scales horizontally by adding more servers. Clients distribute keys using consistent hashing. It's been running in production at Facebook, Twitter, and YouTube since the mid-2000s. Everything is free. BSD license. Every major cloud offers managed Memcached (AWS ElastiCache, Google Memorystore) but the software itself costs nothing to self-host. Solo developers and small teams: if you just need caching and Redis feels like overkill, Memcached is simpler. But honestly, Redis does everything Memcached does plus a lot more. The catch: no persistence, no data structures beyond strings, no pub/sub. Redis has eaten most of Memcached's lunch. The main reason to pick Memcached today is if you need pure multi-threaded caching performance and nothing else.

ArangoDB14.2k★

ArangoDB handles documents, graphs, and key-value lookups in one engine, so you don't need three separate databases. Store JSON documents like MongoDB, query relationships like Neo4j, and do fast key-value lookups, all with the same query language (AQL). C++, mixed licensing (the 'Other' license is Apache 2.0 for the Community Edition). The multi-model approach means fewer moving parts in your stack. Instead of Postgres for relational + Redis for cache + Neo4j for graphs, you run one database. Community Edition is free and covers most features: document store, graph traversals, full-text search (via ArangoSearch, built on IResearch), and clustering. The enterprise features gate: SmartGraphs (optimized distributed graph queries), encryption at rest, and LDAP auth. ArangoGraph (managed cloud) starts around $0.25/hr for a small instance (~$180/mo). Enterprise self-hosted is custom pricing. Solo developers: Community Edition is generous. Run it in Docker, covers documents and graphs. Small teams: CE handles production workloads if you don't need encrypted storage or LDAP. Medium teams: evaluate Enterprise when compliance requires encryption at rest. Large teams: ArangoGraph managed or Enterprise self-hosted. The catch: multi-model means it does everything but isn't best-in-class at any one thing. Postgres beats it for relational queries. Neo4j beats it for deep graph traversals. DuckDB beats it for analytics. ArangoDB wins when your data needs multiple access patterns and you want operational simplicity over specialized performance.

KeyDB12.5k★

Same commands, same protocol, significantly more throughput. KeyDB is fully free and open source under BSD-3. It's a fork of Redis maintained by Snap (yes, the Snapchat company). The headline feature is multi-threading: Redis uses one CPU core no matter how beefy your server is. KeyDB uses all of them. For write-heavy workloads, the difference is measurable. It also supports active-active replication (called Active Replica), which Redis only offers in their paid Enterprise tier. Drop-in compatible means your existing Redis clients, commands, and configurations work without changes. Swap the binary and you're running KeyDB. Solo devs: if Redis works fine for you, don't switch. Small teams hitting Redis bottlenecks: KeyDB is a free upgrade. Growing teams needing active replication: this saves you from paying for Redis Enterprise. The catch: community momentum has slowed since Snap's acquisition. Redis itself has been improving (Redis 7+ added multi-threading for I/O), narrowing the gap. And if you need the managed cloud experience, KeyDB doesn't have one; you're self-hosting.

Garnet11.9k★

Your existing Redis clients work with it out of the box. Free and open source under MIT. Garnet's key selling points: it uses Microsoft's FASTER storage engine under the hood, which is designed for modern SSDs and multi-core CPUs. Benchmarks show significantly higher throughput than Redis for both reads and writes, especially on machines with NVMe drives and many cores. It supports the most common Redis commands, Lua scripting, pub/sub, and cluster mode. No paid tier exists. Microsoft released this as a research-backed open source project. Solo/small teams: stick with Redis unless you have a specific performance bottleneck. Growing teams on .NET stacks: natural fit. Anyone with NVMe hardware and high-throughput requirements: worth benchmarking against Redis and KeyDB. The catch: it's new. Released in early 2024, the Redis command coverage isn't 100%. Some less common commands and modules aren't supported yet. The community is small compared to Redis's massive ecosystem. If your application uses Redis Streams, RedisJSON, or RediSearch modules, Garnet doesn't support those. And running a .NET runtime for your cache layer might feel odd if your stack is otherwise non-.NET.

starrocks11.8k★

StarRocks is a query engine for asking fast questions of enormous data. If your company sits on billions of rows of sales, clicks, or events, this returns complex reports in under a second, even while new data is still streaming in. It speaks standard SQL over the MySQL protocol, so your existing BI tools connect without changes, and it can query data sitting in a lake (Iceberg, Hudi, Delta) without copying it first. Apache 2.0, a Linux Foundation project, and fully open with no feature gating in the core. The real differentiator is real-time updates. Most fast analytics engines, like Druid and ClickHouse, are append-only, so updating a row is painful. StarRocks does primary-key upserts and deletes at second-level speed without tanking query performance. The cost shows up in operations. This is a distributed system with separate coordinator and worker nodes that you cluster, scale, monitor, and tune yourself. Running it seriously means having people who know databases, which is exactly the gap CelerData, the company behind it, sells its managed cloud against. For real-time dashboards and customer-facing analytics, this is a direct substitute for ClickHouse or Druid, and it can replace the serving layer of a Snowflake or BigQuery setup. Solo developers and small teams: powerful, but you probably don't have data at the scale that justifies the ops. Larger teams with real analytics workloads and database talent: this is a genuine open alternative to a five-figure warehouse bill. The catch is the operational weight. The engine is free and excellent, but a self-hosted distributed database is a commitment, not a weekend install. If you don't have the people to run it, the math that makes it free stops being free.

FerretDB11.0k★

FerretDB gives you MongoDB wire protocol compatibility on top of Postgres, so you can use MongoDB drivers and queries without the SSPL license. Your MongoDB queries work, your drivers work, but underneath it's storing data in a real Postgres database. Apache 2.0. The pitch is freedom: use MongoDB's query language and ecosystem without MongoDB's licensing restrictions. It translates MongoDB wire protocol into Postgres SQL. You get Postgres's reliability, backup tools, and ecosystem while your application thinks it's talking to MongoDB. Fully free. No paid tier currently. Self-host only: run FerretDB as a proxy in front of your Postgres instance. Self-hosting is simple: Docker image, point it at Postgres, configure your app to connect to FerretDB instead of MongoDB. Ops burden is moderate; you're really managing Postgres, which most teams already know. Solo developers: interesting if you know MongoDB's query language but prefer Postgres infrastructure. Small teams: useful if you're migrating off MongoDB for licensing reasons. Medium to large: evaluate carefully. FerretDB doesn't support every MongoDB feature yet. The catch: compatibility isn't 100%. Aggregation pipeline support is incomplete, some MongoDB features don't translate to Postgres cleanly, and performance characteristics differ. If you're starting fresh, just use Postgres directly. FerretDB makes the most sense as a migration path away from MongoDB, not as a first choice for new projects.

RedisInsight8.6k★

RedisInsight is the official Redis GUI, and if you spend any real time with Redis, you want it. Browse keys in JSON, hex, or ASCII. Run commands with autocomplete. Watch your slow log live. Profile what's actually hitting the database in real time. It covers OSS Redis, Redis Cloud, and Azure Managed Redis, and it integrates with the JSON, Search, and Time Series modules so the data actually renders the way you'd want it to. Installation is a download. Desktop apps for Mac, Windows, and Linux, a Docker image if you want it containerized, and a VS Code extension if you'd rather not leave your editor. There is no infrastructure to run. The tool talks to whatever Redis you point it at. Use this if you touch Redis at all. Solo, small team, large team, the answer is the same: install it. It's free, it's first-party, and it does the job better than every third-party Redis GUI I've used. The catch: the license is SSPL, not OSI-approved open source. For day-to-day developer use that doesn't matter. If your company has a policy against SSPL or you're shipping it as part of a managed service, read the license carefully before deploying.

hazelcast6.6k★

Hazelcast keeps your application's data in memory so you can read and act on it instantly, instead of waiting on a database every time. It's a distributed in-memory data grid: a fast key-value store spread across a cluster, plus a built-in stream-processing engine for acting on data as it moves. The core is open source under Apache 2.0, with some modules under a source-available community license. This is serious infrastructure. You're running a clustered JVM system, which means capacity planning, memory tuning, and handling node failures and partitioning. It's been in production at banks and large enterprises for years, so it's battle-tested, but it is not a weekend setup. Here's the open-core catch: the features that make it safe for real production live behind the paid Enterprise license. Security (RBAC, LDAP, audit logs), data persistence, WAN replication, and zero-downtime rolling upgrades are all gated. The free edition is a fast distributed cache. Solo and small teams: that free tier is plenty. Larger teams needing security and high availability: budget for Enterprise or the managed Hazelcast Cloud. The closest paid managed service is Amazon ElastiCache or Redis Cloud. If all you need is a cache, Redis is simpler. Hazelcast earns its complexity when you want compute and data living together in one cluster.

ignite5.1k★

Apache Ignite is a distributed database that keeps your hot data in memory so reads and writes happen at RAM speed instead of disk speed. It does more than cache: full ACID transactions, SQL queries, a compute grid that runs code next to the data, and durable storage that survives restarts. Apache 2.0, free to run at any scale. Running it is real work. Ignite is a clustered JVM system, so you are sizing heap and off-heap memory, tuning data regions, planning partitioning and backups, and keeping nodes in sync. A single node starts in minutes. A production cluster that stays consistent under load is a job for someone who knows distributed systems, and you are paying for a lot of memory, because holding data in RAM is the whole point. If you need an in-memory data grid or a distributed cache with SQL and transactions on top, this replaces a lot of moving parts. Solo and small teams rarely need this much machine. Teams with serious throughput requirements, financial systems, real-time processing, large session stores, are the right fit. Smaller alternatives like Redis cover plain caching with far less operational weight if that is all you need. The catch is GridGain. Ignite is genuinely open, but the company behind it sells the enterprise tooling (security, a management console, rolling upgrades) that large clusters lean on. You can run pure Apache Ignite forever, but the smoothest operational path quietly points at a paid product.

ydb4.7k★

YDB is a distributed SQL database built to scale to thousands of nodes without giving up strong consistency or ACID transactions. It handles both transactional and analytical workloads, speaks PostgreSQL and Kafka wire protocols, and scales storage and compute independently. Apache 2.0, open sourced by Yandex, where it runs systems at very large scale. Running YDB yourself is a serious commitment. It is a true distributed system: you deploy a cluster across availability zones, manage storage nodes separately from compute, and own the upgrades and monitoring. Ansible and Kubernetes paths exist, but this is heavy infrastructure. A single-node dev setup is easy. A fault-tolerant production cluster is not a side project. If you genuinely need Spanner-style horizontal scale with strong consistency, YDB is a credible open alternative to CockroachDB or Google Spanner. Most teams do not need this. Solo and small teams are far better served by plain Postgres. Reach for YDB when a single Postgres box truly cannot hold your write volume and you have people who can run distributed storage. The catch is the ecosystem and the origin. Tooling, community, and third-party integrations are thinner than the mainstream databases, and the project's center of gravity is Yandex. The PostgreSQL compatibility helps, but you are betting on a smaller ecosystem to save yourself from a scaling wall most apps never hit.

sqlit4.4k★

SQLite, and more. It's essentially a lightweight database GUI that runs in your terminal window: no browser, no Electron app, just your keyboard and your data. and. MIT licensed, Python. The interface lets you browse tables, run queries, view results in a formatted table, and switch between databases. It supports multiple database backends through a unified interface, which is useful if you work with different databases across projects. Completely free. No paid tier, no hosted version. Install via pip and connect to your databases. Solo: great for quick database checks without opening a heavy GUI. Small teams: useful for developers who live in the terminal and want fast data access. Medium to large: this is a personal productivity tool, not a team collaboration platform. For shared database management, look at DBeaver or a web-based tool. The catch: it's early-stage, with high velocity means it's catching attention, but the feature set is thin compared to mature tools like DBeaver or DataGrip. No saved queries, no ER diagrams, no data export wizards. It's a browser, not a workbench. If you need advanced features, this won't replace your existing tool, but for quick terminal queries, it's clean and fast.

paimon3.3k★

Apache Paimon is a table format for data lakes. You store huge amounts of data on cheap object storage (S3, GCS) and query it with both streaming and batch jobs without two separate pipelines. Apache 2.0 licensed, fully open source. Top-level Apache project, originally Flink Table Store before it graduated. Production setup is not trivial. You need a query engine (Flink or Spark, sometimes both), a metastore, and an object storage bucket. The format itself is the easy part. Running it at scale means managing the surrounding cluster, like any Apache analytics tool. Single-node testing works on a laptop, production is a distributed system. Compare to Apache Iceberg, Delta Lake, and Apache Hudi. Paimon's pitch is better streaming integration with Flink. Iceberg has wider engine support. Delta Lake is the safer pick if you already live in Databricks. Hudi owns the niche in mutable upserts. The catch: lakehouse table formats are still a contested space. Picking Paimon means betting on its trajectory rather than choosing the safest option. If you are not running Flink, Iceberg is the easier choice.

kingfisher1.1k★

Kingfisher is an experimental Rust-based tool from MongoDB's org. The description is sparse and the homepage points to the Apache 2.0 license page, not an actual product site. This is a nascent project. Based on the repo, Kingfisher appears to be a data migration and validation tool for MongoDB, written in Rust for performance. It handles schema validation, data integrity checks, and migration workflows for MongoDB deployments. Apache 2.0, fully free. No paid tier. The catch: this is extremely early-stage. No real homepage, sparse documentation, and unclear roadmap. Being under MongoDB's GitHub org doesn't guarantee long-term support. Large companies abandon experimental repos constantly. If you need MongoDB migration tooling today, this is interesting to watch but not something to build workflows around. Wait for a proper release and documentation before depending on it.

stac890★

Stac is a backend-as-a-service built specifically for the Dart ecosystem. Think Firebase or Supabase but written in Dart, so your entire stack speaks the same language. Free and open source under MIT. You self-host it and get auth, a database layer, file storage, and serverless functions. The Dart-native angle means you write backend logic in the same language as your Flutter frontend, no context-switching between TypeScript and Dart. The catch: this is very early. The Dart backend ecosystem is tiny compared to Node.js or Python. If Stac's development stalls, you're stranded on a niche framework with limited community support. Firebase and Supabase have massive communities, extensive documentation, and proven scale. Stac's only real advantage is the all-Dart stack, and that only matters if Dart-everywhere is a priority for your team.