PostgreSQL for Money Data
Constraints, decimals, and sync strategies that keep balances trustworthy.
Money data is unforgiving. A one-rupee drift destroys trust. That is why BolKharcha uses PostgreSQL with careful numeric types and constraints instead of casual floating point.
Accounts, transactions, transfers, and loans are related on purpose. Foreign keys and transactional writes prevent orphan states that JSON blobs love to create.
Optimistic UI keeps the app feeling instant. The server remains the referee. Conflict resolution and idempotent writes matter when networks flake.
Reporting queries should be boring and indexed. Fancy analytics are useless if month summaries take seconds on a mid-tier phone network.
Migrations are product decisions. Changing how balances are computed mid-flight requires backfills and honesty in release notes.
I prefer explicit ledger entries over mutable balance fields alone. Balances can be derived; history must be durable.
If you store money, treat your database like a vault: clear rules, audited changes, no vibes-based schema.