3 ms·
> For each financial transaction, there would be 10-20 SQL queries back and forth across the network, while holding row locks. Cant you do that with postgresql
by victorbjorklund 2y ago
> For each financial transaction, there would be 10-20 SQL queries back and forth across the network, while holding row locks.
Cant you do that with postgresql with custom functions? That way you just send the info once and it does all the processing in the db.
- jorangreef 2y agoSee this comment which answers this question in detail: https://news.ycombinator.com/item?id=41061851 https://news.ycombinator.com/item?id=41061851 TLDR: Stored procedures (or an extension, or an in-process embedded DBMS) would help with the external row locks but wouldn't solve the internal locks (that couple I/O and CPU), and wouldn't approach the same degree of group commit, or network request amortization that TigerBeetle does. i.e. You're still using the anatomy of a general-purpose DBMS design, whereas TigerBeetle has a completely different anatomy in the storage engine and consensus protocol—all specialized for transaction processing. Again, the anatomy is different (think duck for OLAP, elephant for OLGP, or beetle for OLTP).