Choose a database by the relationships, invariants and access patterns the application must support. A document model is not automatically inconsistent, and a relational schema does not automatically make every business operation correct.
A property payment workflow offers a concrete comparison: record the incoming payment, relate it to a lease, update the ledger and prevent the same external payment from being applied twice.
Represent money deliberately
PostgreSQL's numeric type supports exact decimal calculations within its declared precision and scale. Values may still be rounded to the configured scale, so the business rounding policy must be explicit.
MongoDB also supports decimal monetary representations, including Decimal128, as described in its monetary-data guide. It is incorrect to assume that MongoDB forces every amount into a JavaScript binary floating-point number.
Preserve the intended representation through request parsing, application calculation, database drivers and output. Converting an exact stored value to an imprecise application number can reintroduce the problem.
Decide which changes must be atomic
MongoDB supports multi-document transactions, as well as atomic single-document operations. Their cost and appropriate use depend on the data model and deployment.
PostgreSQL transactions can group related writes across tables. In either system, define isolation, retries and uniqueness rules. A transaction alone does not prevent the same external payment from being submitted twice.
For the payment example, use a unique external transaction reference and coordinate its insertion with the ledger effect. Test concurrent duplicate requests and the response when a previously completed request is repeated.
An external payment-provider call is not automatically part of the database transaction. Handle uncertain provider outcomes through idempotency and reconciliation.
Model relationships from the queries
PostgreSQL foreign keys can enforce referenced-row existence and configured deletion behavior. They do not by themselves establish that a lease is active or a ledger balances.
In MongoDB, embedding can fit data read and updated together; references can suit independently growing entities. Avoid unbounded history inside one document merely because nesting is available.
Write the important queries before choosing the shape: overdue balances across properties, a single lease history and reconciliation by payment reference. Inspect plans and indexes with representative data instead of assuming either database always scans or always responds in milliseconds.
Evolve both models intentionally
MongoDB offers schema validation with configurable rules and enforcement behavior. Flexible schema is a choice to manage, not an absence of all validation.
For SQL migrations, Flyway's validate command compares applied and available migrations; SQL checksums use CRC32, not SHA256. Validation detects specified history differences. It does not prove that environments contain identical data or that a migration is operationally safe.
Test backward compatibility, partial rollout and recovery.
Make the choice reviewable
Document the invariants, common queries, expected growth and operational experience of the team. Prototype the difficult path and test failures, not only initial CRUD.
The Real Estate API provides a PostgreSQL-based implementation to inspect. Its existence does not establish a failed MongoDB deployment or a universal database winner. The defensible decision is the one supported by your workload and verification.
Sardar Mukhshaf
Full-Stack & DevOps Engineer
I build scalable web applications, secure backend systems, and production-ready cloud infrastructure. My engineering focus spans interface design, API architecture, deployment pipelines, and observability. Follow for more deep dives into system architecture, performance engineering, and emerging technologies.
More from the practice
Keep the useful ideas close.
Follow new articles with your preferred RSS reader.
Open the RSS feed ↗
