Similar, yes. But not near the same performance, TB is entirely built around this concept so they became pretty good at it. It's like comparing a lambo and a beetle (no pun intended).
But honestly, if double-entry really become a thing I foresee traditional DBMS agglutinating it just like they did with vector and object databases, getting the long tail of the market.
You could, but TB brings a whole lot of debit/credit primitives out of the box (making it dead simple for e.g. 2PC money movement across third party systems, or transactions of thousands of transactions, to express complex financial contracts)… that are Jepsen-tested, which run multi-AZ, and which would probably take months if not years to replicate on PG. Even then, the internal concurrency control of PG’s storage engine would just get hammered by the contention, and would struggle to approach TB’s replicated performance, even if PG were single node.
Nothing takes “months or years” anymore, if you really wanted this it could be done fairly quick by someone who knows what they’re doing and you don’t layer it in bureaucracy.
It would be nice. I can think of things for which I want to process a financial transaction and something else in one atomic transaction (e.g. selling a ticket - something I am working on right now) and have both content (e.g. product descriptions) and finance in a single store.
