In this post, I’ll walk through a set of common misconceptions that drive teams to introduce new infrastructure when they don’t need to. All of these can be solved with vanilla PostgreSQL 18 using standard extensions available on RDS, with no special infrastructure and no distributed-systems cosplay.

The database can be used for many things people often miss:

• user roles (finance) for modularity. In particular, a proper role can be used for defining very precise interfaces on top of database objects
• domains can be defined as an application of the abtract data type to database management
• a table for transfers can be stored with a system-time temporal table
• account audits (store old versions for logs)
• transaction state machine with functions
• record size estimation
• Heap-Only Tuple to avoid write amplification when primary keys are aligned with immutable columns. It enables faster updates. See https://ebellani.github.io/blog/2026/all-you-need-is-postgresql/#introduction:~:text=Enabling%20HOT%20Updates%20for%20Transfers,-By
• excellent OLTP (quick read and write individual rows) with a primary key reflecting the access pattern
• view to reuse queries from multiple tables
• excellent OLAP: large volumes of data while allowing quick query response times: a finance.balance_ledger table stores a snapshot of both balances after every transaction.
• incremental maintenance via triggers
• correct isolation with alter role finance set default_transaction_isolation = 'serializable';. If a cyclic transaction is detected, then one of the transaction fails. The application must be prepared to retry aborted transactions, but the invariants are never violated.

Key takeaways:

• 766 TPS overall with 0 failed transactions. The startup target of 10,000 transfers/day is ~0.12 TPS. We exceed that by over 6,000x, confirming massive headroom on modest hardware.
• 0 serialization failures: Despite 10 concurrent clients writing to 100 accounts under SERIALIZABLE isolation, no transactions were aborted. The working set is distributed across enough accounts that write contention is negligible at this scale.
• 8ms average read latency: The UNION ALL view over 4 tables plus the balance ledger lookup completes well within interactive response time, even as the tables grow throughout the 60-second run.
• 33ms average write latency: Each write transaction exercises the full constraint set that implements complex business logic (audit trails, time constraints, balances, etc) all within 33ms. This is the true cost of enforcing every business rule at the data level, and it is more than acceptable.

The full SQL is provided at the end.