Data for Multi-platform

The all-in-one convenience creates dependency. Complex queries hit performance limits. Self-hosting requires significant operational knowledge.

SQLite limitations still apply—no concurrent writes from different regions. The embedded replica model has a learning curve. Less battle-tested than Postgres.

License: not MIT. Since Redis 8 the server is tri-licensed RSALv2 / SSPLv1 / AGPLv3 at your choice — AGPLv3 is the only OSI option and carries network copyleft; 7.4–7.x was RSALv2/SSPLv1 only. If you need BSD-3 Redis-protocol, look at Valkey. Memory-bound storage is expensive at scale. Persistence options have tradeoffs. Clustering adds complexity.

HTTP adds latency compared to native Redis protocol. High-throughput workloads get expensive. Some Redis features are not available.

Vendor lock-in for a core AI capability. Costs scale with vector count and queries. Self-hosting is not an option.

Operational burden of self-hosting. Smaller ecosystem than Pinecone. Some advanced features require understanding internals.

Not a general-purpose database—updates and deletes are expensive. Operational complexity for self-hosting. The learning curve for optimal schema design is steep.

License first: TimescaleDB is split — the core is Apache-2.0, but features in the tsl directory (compression, continuous aggregates and more) are under the Timescale License (TSL), which is source-available and bars offering TimescaleDB as a database service. Adds complexity to Postgres operations. Some hypertable features have limitations. The learning curve for optimal performance is real.

Not for OLTP workloads—it is analytics-focused. Single-node limits apply. Less ecosystem than traditional databases.

Single writer at a time limits write concurrency. Not designed for network access. Feature set is smaller than Postgres.

Codegen from SQL - not Prisma/Drizzle ORM, not a database. Schema migrations are still yours (golang-migrate, Atlas, etc.). Language support depth varies.

You own the Database interface (or codegen it). No schema designer, no magic relations like Prisma.

Business Source License 1.1 — NOT OSI open source. You may not offer SurrealDB as a commercial DBaaS without a deal; code flips to Apache-2.0 after the change date (3.0 → 2030-01-01). Enterprise HA/security features are paid. It is not MIT/Apache OSS.

Vs Prisma/Drizzle (typed app ORMs) and Hasura (GraphQL instant API): PostgREST is REST-from-schema, not an ORM and not GraphQL. Complex business workflows still want app code; you lean on SQL views/RPCs and RLS design instead of controllers.

It is an extension, so on self-hosted Postgres you compile or package it yourself, and on managed Postgres you are limited to the version your provider ships. HNSW indexes on large tables are slow to build and need plenty of maintenance_work_mem; at hundreds of millions of vectors you will be tuning, quantizing or partitioning. Filtered queries can return fewer rows than expected with approximate indexes unless you use iterative scans (0.8+).

It is single user and single connection, so it is not a replacement for a Postgres server behind a multi-user backend. Performance and memory are bounded by the WASM runtime, and only the extensions the project has ported can be loaded. It is still 0.x, so expect API changes between minor versions.

RESP compatibility is not full Redis: check your exact commands and modules against Garnet's API docs before swapping it in. Custom extensions are written in C#/.NET, so this fits best in a .NET team. The headline latency numbers come from the project's own benchmarks on Azure VMs. The managed Azure Cosmos DB Garnet Cache is a separate paid service; the OSS server is free.

It is a translation layer, not a distributed object store: durability and scaling come from the file system underneath. S3 API coverage is broad but not identical to AWS, so test the calls your SDK uses. Smaller community than MinIO or Garage.

It is a big Java desktop app: startup and memory use are heavier than native clients like TablePlus or a terminal client. Some NoSQL connectors, cloud features and team tooling sit in the paid DBeaver PRO editions, so the free Community edition is relational-first. The UI is dense.

A production cluster is several components (TiDB, TiKV, PD, optionally TiFlash) across at least three nodes, which is a lot of ops for a small app. MySQL compatibility is high but not total, so test your queries and features. The managed TiDB Cloud is PingCAP's commercial service.

Several of the faster storage adapters and some plugins are paid premium add-ons, so check which ones you need before you commit. Conflict handling in local-first sync is your design problem, not something the library makes disappear. The API surface is large.

Officially supported on Linux amd64 and arm64 only; Mac and Windows support was dropped in 2021, so use Docker there. The company behind it has changed hands more than once, which matters for a long-term database bet. Its query language and schema model are its own, not Cypher.

Writes go through the Raft leader, so write throughput is that of one node; it is for reliability, not write scale-out. You talk to it over its HTTP API rather than a standard SQLite driver, and non-deterministic SQL functions need care. Cluster sizing and quorum are now your job.

Benchmarks are the vendor's own. Automatic tiering of cold partitions to object storage, replication and other features are in QuestDB Enterprise; in open source you convert partitions to Parquet yourself. It is built for append-heavy time-series, not general OLTP with frequent updates.

It is a Python app, so startup is slower than psql and you need a Python environment. Some psql meta-commands and scripting behaviours differ, so keep psql for scripts. Huge schemas can make the completion refresh slow.

It is a query engine, not storage: you still need a catalog and files or databases underneath. Running a coordinator plus workers on the JVM needs memory tuning, and building from source requires Java 25 and Docker. Starburst sells the commercial distribution; plain Trino is fully open.

The classic deployment needs Kafka and Kafka Connect, which is heavy infrastructure for a small team; Debezium Server avoids Kafka but adds its own config. Each database needs log access and settings (logical replication, binlog) that DBAs must allow. Schema changes and snapshots take planning.

Sharding means choosing a distribution column well; a poor choice makes cross-shard queries slow. AGPL-3.0 matters if you modify Citus and offer it as a service. Not every managed Postgres lets you install it, so you often self-host or use Azure's managed version. Cluster ops are more involved than one Postgres box.

Streaming SQL is a different mental model from batch: state size, watermarks and view design decide your costs. A cluster has several components and uses object storage for state. The project's marketing leans on agentic AI; the core value is incremental views, not AI. RisingWave Cloud is the commercial option.

The README now positions it as an enterprise warehouse for AI agents, and the recommended start is Databend Cloud (free to start, commercial beyond that); self-hosting a cluster is more work. Smaller ecosystem than ClickHouse or DuckDB. Releases are frequent nightly-style builds, so pin versions.

It is mostly a one-maintainer project, and releases are a few a year. Data must fit in memory. It is a specialised geofencing engine, not a general GIS database; for complex spatial SQL, PostGIS is the tool.

Performance claims (3x faster on average) are the project's own. A cluster is frontend and backend nodes to size and operate. It is an analytics engine, not a transactional database. CelerData sells the commercial version.

Grist Labs sells an edition with extra features and runs free and paid hosted plans; check that the features you need are in Community. Python formulas run in a sandbox that needs extra setup for safe multi-user self-hosting. Large datasets are not its strength.

It has no tagged releases, so self-hosters build from main. Diagrams live in browser storage by default, so export them or you can lose them. It designs schemas; it does not connect to a live database to reverse-engineer or apply changes. AGPL-3.0 if you offer a modified version as a service.

Still 0.x. Some drivers are only included in certain build tags, so check your binary supports the database you need. Completion and meta-commands are not as deep as pgcli or the native clients.

It is a mature, opinionated object model rather than plain SQL, so it feels dated next to Supabase or PocketBase, and complex relational queries can fight the abstraction. You operate the database, scaling and backups yourself. Releases are frequent, so pin versions and read the changelog before major upgrades.