Databases

Appwrite55.3k★

Appwrite is the open source Firebase that actually lets you self-host. Authentication, databases, storage, serverless functions, real-time subscriptions — the complete backend-as-a-service in Docker containers. If Firebase's vendor lock-in makes you nervous, Appwrite is the exit strategy. For indie hackers building mobile or web apps who want to skip building a backend, Appwrite gets you to MVP fast. Supabase is the main competitor — Postgres-based, more SQL-friendly, larger community. Firebase is the commercial benchmark but locks you into Google. PocketBase is lighter (single Go binary) but less feature-complete. Best for developers who want a batteries-included backend they can self-host or use via Appwrite Cloud. The SDK support across platforms (Flutter, React Native, web) is excellent. The catch: BSD-3 licensed, which is great. But the Docker-based self-hosting is resource-heavy — not ideal for a $5 VPS. The database is MariaDB under the hood, which limits advanced query capabilities compared to Supabase's Postgres. And the ecosystem, while growing, is still smaller than Firebase or Supabase.

ClickHouse46.5k★

ClickHouse is the analytics database that processes billions of rows per second like it's nothing. Columnar storage, vectorized execution, and aggressive compression make it the go-to for real-time analytics dashboards, log analysis, and time-series data at scale. If you're building analytics on large datasets — product metrics, event streams, log aggregation — and need sub-second queries, ClickHouse delivers. DuckDB is the embedded alternative for single-machine analytics (think SQLite for OLAP). Apache Druid and Pinot handle similar real-time analytics workloads. Commercially, BigQuery, Snowflake, and Redshift solve the same problems with managed infrastructure. The SQL interface is familiar, the compression ratios are remarkable (10-40x), and the performance on aggregation queries is genuinely jaw-dropping. The catch: running ClickHouse in production is a second full-time job. Distributed cluster management, replication, and query tuning require dedicated expertise. It's a terrible choice for OLTP workloads — no transactions, no row-level updates. For indie hackers, ClickHouse Cloud (managed) removes the ops burden but costs money. If your data fits in memory, DuckDB gives you similar query performance with zero infrastructure.

TiDB39.9k★

TiDB is the distributed SQL database that lets you scale MySQL horizontally without changing your application code. MySQL-compatible wire protocol, HTAP (real-time analytics on transactional data), and automatic sharding. It's Google Spanner's architecture, open-sourced. If you've outgrown a single MySQL instance and need horizontal scaling with strong consistency, TiDB is the MySQL-ecosystem answer. CockroachDB does the same for PostgreSQL. YugabyteDB supports both protocols. Vitess (from YouTube) shards MySQL but requires more application awareness. Commercially, Aurora and Cloud Spanner are the managed distributed SQL options. The HTAP story is compelling: TiKV handles OLTP, TiFlash handles OLAP, and they replicate in real-time. No ETL pipeline from production to analytics warehouse. The catch: running TiDB in production means operating a distributed system with multiple components (TiDB, TiKV, PD, optionally TiFlash). That's a significant ops burden for small teams. Performance for simple OLTP queries won't match a well-tuned single-node MySQL. And if you don't actually need horizontal scaling, a single Postgres instance with read replicas is simpler and cheaper.

CockroachDB32.0k★

CockroachDB is Postgres-compatible SQL that survives datacenter failures without you losing sleep. It distributes data across nodes automatically, handles replication, and gives you serializable isolation by default. If your app needs to be up no matter what, this is the database. For indie hackers, the free tier (10 GiB on CockroachDB Serverless) is generous enough to build real products. But the real audience is teams outgrowing single-node Postgres who need multi-region or high availability without hand-rolling replication. PlanetScale does similar things for MySQL. Neon gives you serverless Postgres without the distributed complexity. Vitess scales MySQL horizontally but requires more manual sharding. Best for apps where downtime costs real money — fintech, e-commerce, SaaS with global users. The catch: the license changed to a proprietary BSL (Business Source License). You can't offer CockroachDB as a service. Performance on single-node is slower than plain Postgres — the distribution layer adds latency you don't need at small scale. Don't pick it for a side project.

SurrealDB31.7k★

SurrealDB promises to be your only database — documents, graphs, relations, vectors, time-series, and full-text search in one engine with one query language (SurrealQL). Think MongoDB meets Neo4j meets Postgres, but in Rust and with a single binary. The ambition is real, and early benchmarks show competitive performance. If you're prototyping something that genuinely needs multiple data models — a social app with graph relationships AND document storage AND vector search — SurrealDB lets you skip the "three databases duct-taped together" phase. MongoDB is the document-only incumbent. Neo4j owns graph. Postgres with pgvector handles the pragmatic multi-model case. The catch: SurrealDB uses a custom BSL-style license — check the terms. The v2.x releases are improving fast, but production case studies are thin. The "one database for everything" pitch sounds great until you need the specialized performance that purpose-built databases deliver. For most indie hackers, Postgres with the right extensions is the safer bet.

InfluxDB31.4k★

InfluxDB is the time-series database you've probably already heard of. It's built for metrics, events, and IoT data — anything with a timestamp. The query language (Flux, now moving to SQL) and built-in downsampling make it the default choice for monitoring stacks. If you're tracking server metrics, sensor data, or application performance, InfluxDB handles the write-heavy workload that regular databases choke on. TimescaleDB extends Postgres with time-series superpowers and lets you keep one database. Prometheus is the standard for pull-based metrics but isn't a general-purpose time-series DB. Datadog does it all as a service but costs a fortune. Best for IoT projects, custom monitoring dashboards, or any system generating high-frequency timestamped data. The catch: InfluxDB 3.0 was rewritten in Rust and dropped Flux for SQL — a massive breaking change from v2. The open source version of v3 is more limited than the commercial offering. If you built on Flux, you're looking at a migration. And TimescaleDB might be simpler if you already run Postgres.

RethinkDB27.0k★

The database that solved realtime push queries — then the company behind it died. RethinkDB lets you subscribe to query results and get live updates when data changes, no polling required. For realtime apps — chat, dashboards, collaborative editors — the developer experience is still unmatched. MongoDB with Change Streams offers similar functionality but bolted on, not native. Firebase Realtime Database is the managed alternative but locks you into Google. Supabase offers Postgres with realtime via websockets. CouchDB has change feeds but a smaller community. The changefeeds API is elegant: any query can become a live subscription. The ReQL query language is more expressive than MongoDB's query syntax. And the admin UI is genuinely beautiful. The catch: the company shut down in 2016, and while the community keeps it alive, development is slow and the project actively seeks maintainers. The 27K stars are legacy momentum. For new projects in 2026, Supabase Realtime or Firebase give you the same capabilities with active development and commercial support. Using RethinkDB is a bet on a community that's running on fumes.

TimescaleDB22.2k★

TimescaleDB is time-series data without leaving Postgres. It's an extension, not a separate database, which means your existing SQL knowledge, tools, and ORMs all just work. For teams already running Postgres, adding time-series capabilities is an ALTER EXTENSION away. InfluxDB is the purpose-built alternative — faster at low-cardinality ingestion with its new 3.0 Apache Arrow architecture. QuestDB is the speed demon for analytics workloads. For commercial managed time-series, Datadog and New Relic bundle it into their monitoring stacks. Use TimescaleDB if you're already on Postgres and need time-series alongside relational data. It outperforms InfluxDB 3.5x at high cardinality (many devices/metrics). The catch: the license changed from Apache 2.0 to a "Timescale License" that restricts offering it as a managed service — fine for your own use, problematic if you're building a DBaaS. And it inherits Postgres's storage overhead, so pure time-series workloads may be leaner on InfluxDB.

Dgraph21.6k★

Dgraph is the graph database that bets on GraphQL as its native query language. If your API is already GraphQL, Dgraph eliminates the translation layer — your schema defines the graph, and queries hit the database directly. That's a real productivity win for API-first teams. Neo4j is the dominant player — bigger community (200K+ developers), more tooling, more tutorials. For commercial managed graph, Amazon Neptune and Neo4j Aura are the options. TigerGraph targets enterprise analytics at scale. Use Dgraph if you're building a GraphQL API with complex relationships and need horizontal write scaling. Its predicate sharding distributes data across Raft groups for parallel processing. The catch: much smaller community than Neo4j, which means less Stack Overflow help when you're stuck. The project has had turbulent governance — the original company pivoted multiple times. And if your team already knows Cypher, switching to DQL/GraphQL adds learning overhead for no clear gain.

Neon21.3k★

Neon is serverless Postgres that finally makes database branching real. Fork your entire database like a Git branch — for testing, staging, or previews — without copying data. The cold-start autoscaling means you pay nothing when your database is idle. This is what managed Postgres should feel like. If you're building a SaaS and want Postgres without managing infrastructure, Neon is the modern choice. Supabase bundles more (auth, storage, real-time) but gives you a regular Postgres instance. PlanetScale does branching for MySQL. RDS is AWS's managed Postgres but has no branching or scale-to-zero. Best for indie hackers who want Postgres with a generous free tier (0.5 GiB storage, 24/7 compute). The Vercel integration makes preview deployments with branched databases trivial. The catch: the free tier compute is shared and can be slow during cold starts. Storage beyond the free tier adds up. Some Postgres extensions aren't supported yet. And "serverless" means connection pooling quirks — you'll want to use their serverless driver or a pooler for high-concurrency apps.

Vitess20.9k★

Vitess is how YouTube scaled MySQL to handle billions of queries. It's a database clustering system that adds horizontal sharding, connection pooling, and query routing to MySQL without changing your application code. Battle-tested at Google-scale. If your MySQL database is hitting performance limits and you're considering a rewrite to a distributed database, Vitess lets you keep MySQL and scale it horizontally. PlanetScale is literally built on Vitess (hosted, managed, easier). CockroachDB offers similar horizontal scaling but with Postgres compatibility. TiDB is another MySQL-compatible distributed database with less operational complexity. Best for teams with existing MySQL apps that need to scale beyond a single server without rewriting queries. This is infrastructure-team territory, not solo-founder territory. The catch: operating Vitess is a full-time job. The learning curve is steep — topology servers, vtgate, vttablet, and sharding schemes all need understanding. If you're not already at MySQL's scaling limits, you're adding complexity for no reason. PlanetScale exists precisely because running Vitess yourself is hard.

QuestDB16.8k★

QuestDB is the time-series database that embarrasses InfluxDB on benchmarks. Built from scratch in Java, C++, and Rust with a columnar engine, it ingests 18M+ rows per second and queries 43-418x faster than InfluxDB on complex analytics. It speaks SQL (not Flux, not InfluxQL — actual SQL) and accepts data via the InfluxDB line protocol, so migration is nearly painless. If you're building real-time dashboards, IoT pipelines, or financial data systems, QuestDB deserves your shortlist. TimescaleDB is the PostgreSQL-native alternative — great if you want one database for everything, but inherently slower for pure time-series workloads. InfluxDB 3 Core has a 72-hour retention limit on the free tier. Datadog is the managed commercial option bleeding you per metric. The catch: QuestDB is Apache-licensed but the company pushes you toward their cloud. The ecosystem is younger than TimescaleDB's — fewer integrations, smaller community, less Stack Overflow coverage. And "fast" means nothing if your dataset fits in PostgreSQL with a time index.

TiKV16.6k★

TiKV is a distributed transactional key-value store built for the scale where etcd breaks and Redis Cluster gets awkward. Created by PingCAP as the storage engine underneath TiDB, it shards data automatically across nodes, supports ACID transactions, and scales to 100+ TB. It's a CNCF graduated project — the same tier as Kubernetes itself. If you need a distributed KV store with real transactions and horizontal scaling, TiKV is the serious option. Etcd is simpler but doesn't shard — it fully replicates on every node, so it tops out at a few GB. CockroachDB competes at the SQL layer but switched to a restrictive enterprise license. FoundationDB (Apple) is the alternative for extreme throughput. The catch: TiKV is a building block, not a product. You'll almost certainly use it through TiDB (the SQL layer) rather than directly. Running a TiKV cluster requires PD (Placement Driver) nodes for scheduling — it's three components minimum. For most indie projects, this is nuclear-grade infrastructure for a problem you don't have yet.

libSQL16.5k★

SQLite that learned to talk over the network. libSQL is Turso's fork of SQLite that adds server mode, replication, and open contributions — things SQLite's governance model doesn't allow. The result is an embeddable database that also works as a remote server via WebSockets and HTTP. SQLite is the parent project — 4 billion deployments, bulletproof reliability, but no network access and no accepting outside contributions. Postgres is the production default for anything needing multi-user access. PlanetScale and Neon offer managed MySQL and Postgres respectively. The JavaScript SDK hit 800K weekly downloads, proving there's real demand. For edge deployments, local-first apps, and per-tenant databases, libSQL is a legitimate production choice in 2026. Cloudflare D1 uses similar SQLite-at-the-edge concepts. The catch: Turso is already working on a Rust rewrite (Limbo) intended to replace libSQL long-term. That means you might be building on a transitional technology. The server mode is production-ready, but "fork of SQLite" means maintaining compatibility with upstream changes forever. And for anything needing concurrent writes from multiple servers, Postgres is still the safer choice.

Neo4j16.2k★

Neo4j is the graph database you reach for when relationships ARE the data. Social networks, recommendation engines, fraud detection, knowledge graphs — anywhere the connections between entities matter more than the entities themselves. If your queries involve traversing relationships (friends-of-friends, shortest path, pattern matching), Neo4j handles them elegantly where SQL databases choke on recursive joins. ArangoDB is the multi-model alternative offering graphs plus documents plus key-value. Amazon Neptune is the managed graph database. Dgraph was the open-source challenger but has faded. Cypher, Neo4j's query language, reads almost like English for graph patterns. The visualization tools make exploring data intuitive. The community edition handles surprisingly large datasets. The catch: the Community Edition is GPLv3, meaning your application code may be affected if you're distributing software. The Enterprise Edition requires a commercial license. Also, Neo4j struggles with large-scale analytical queries compared to purpose-built analytics databases. If your graph has billions of edges, you'll need careful schema design and probably the enterprise tier.

ScyllaDB15.4k★

ScyllaDB is Cassandra rewritten in C++ by people who thought Java was holding it back — and the benchmarks prove them right. 7x faster scaling, 8x higher throughput, 32x faster compaction, all while being API-compatible with Cassandra and DynamoDB. Drop-in replacement, dramatically better performance. If you're running Cassandra and fighting GC pauses, tail latency spikes, or compaction storms, ScyllaDB is the upgrade path. Same CQL queries, same drivers, better numbers. DynamoDB is the managed alternative at 40x the cost with 4x worse latency. Apache HBase is the HDFS-native option for Hadoop shops. MongoDB handles similar workloads but with different consistency tradeoffs. The catch: ScyllaDB's open-source edition uses a custom license that isn't purely OSS — the enterprise features (like encryption at rest, audit logging) require a paid plan. The "shard-per-core" architecture is brilliant for performance but makes operational troubleshooting different from Cassandra. And you still need to understand distributed database concepts — ScyllaDB doesn't make the CAP theorem disappear.

ArangoDB14.1k★

One database for documents, graphs, and key-value — no Frankenstack required. ArangoDB's multi-model approach means you can store JSON documents, run graph traversals, and do key-value lookups without stitching MongoDB, Neo4j, and Redis together. For complex domains with interconnected data, that's a real simplification. MongoDB dominates document storage with a massive ecosystem. Neo4j owns graph databases. PostgreSQL with JSONB handles most document needs for teams that already know SQL. Each beats ArangoDB in their specialty. AQL, ArangoDB's query language, is the real differentiator — SQL-like syntax that combines document queries and graph traversals in a single statement. Multi-document transactions work properly, and horizontal scaling is built in. The catch: the license changed from Apache 2.0 to a business source license — check the terms before building a commercial product on it. Jack of all trades, master of none: it won't outperform specialized databases in any single model. Community is smaller than MongoDB or Postgres, meaning fewer drivers, tutorials, and Stack Overflow answers.

FerretDB10.9k★

MongoDB's API on top of PostgreSQL, for teams who want document storage without the SSPL license headache. FerretDB is a proxy that translates MongoDB wire protocol to SQL, so your existing MongoDB drivers and tools work unchanged while your data lives in Postgres. MongoDB itself is the obvious comparison — faster, more features, but SSPL-licensed. PostgreSQL with JSONB gives you document storage natively without a proxy layer. CouchDB offers a true document database with replication. FerretDB v2.0 shipped with significant speed improvements and a vision for a vendor-neutral NoSQL standard. Use MongoDB Compass, Studio 3T, or any MongoDB client — they just work. Your data is queryable with both MongoDB queries and standard SQL. The catch: FerretDB is a translation layer, not a database. Complex MongoDB aggregation pipelines may not translate perfectly. Performance will never match native MongoDB — there's overhead in every query translation. And if you're starting fresh, just use PostgreSQL with JSONB directly instead of adding a proxy layer. FerretDB makes most sense for migrating existing MongoDB apps to Postgres.