An Honest Comparison
Cassandra, MongoDB, Postgres and MySQL compared with a decision framework, Jepsen findings read critically, when a document database is a relational database with weaker constraints, polyglot persistence and the consistency tax between stores, and what most fintech workloads actually need.
Choosing with mechanism, not fashion
| need | best fit | why |
|---|---|---|
| money: ledgers, balances, invariants | Postgres or MySQL (or a NewSQL system at global scale) | transactions, constraints, joins, mature tooling |
| very high write throughput, time series, multi-region always-writable | Cassandra or ScyllaDB | LSM writes, leaderless replication, tunable consistency |
| self-contained aggregates with flexible shape (catalogues, content, KYC submissions) | MongoDB, or Postgres JSONB | documents read and written whole |
| event history and audit trails at scale | Cassandra, or Kafka plus a warehouse | append-heavy, time-partitioned |
| caching and ephemeral state | Redis | memory speed (course 7) |
Jepsen (jepsen.io) has tested both systems repeatedly; past reports found issues under particular configurations (for example, MongoDB reads and writes below majority concerns, and Cassandra lightweight transaction bugs), most since fixed. Read reports for the configuration you run, and set concerns deliberately. Polyglot persistence adds a consistency tax: every additional store needs CDC or outbox plumbing to stay in sync (Scaling course P7). Start with one relational database and add stores when a measured need appears.