Do you think it would be more fair to suggest that OLTP workloads have 0% contention? That debit/credit sets never intersect?
In practice, we're seeing that our customers are already some of the largest brokerages, wealth managements or exchanges, in their jurisdictions, even national projects, and all of them with decades of Postgres etc. experience, some even running installations with 200 Postgres/MySQL machines backing their sharded core ledger.
They're not junior engineers. For example, they know about stored procedures, but the problem of concurrency runs deeper, into the storage engine itself.
At least for our customers, for the seasoned payments engineers, OLTP contention is a killer. They're tired of scaling outside the DBMS, and the complexity of expensive reconciliation systems. Several of them are even leaving their Chief Architect positions and starting TB-related startups—I know of at least 4 personally, from fintech brands you will recognize, and probably use.
I hope the spirit of our talks, trying to get the big ideas across, to make people aware of contention and Amdahl's Law, is clear, and that you take it in good faith, to the extent that we show it ourselves.
Oh I totally agree the world needs to be more aware of Amdahls law, and I appreciate that you make it known (I believe I even learned it from you). I just think that the communication is sometimes too much "it's our way or the bad way", if that makes sense?
I don't think they have 0% contention, and I agree that contention is the bane of a dev's existence, but I don't think it's as cut and dry as only looking at Amdahl's.
Specialized systems have done really well to handle contention: My go-to example is LMAX. I think I remember a talk where the devs said they were pulling 6M orders per second, and ofc the stock market has an aggressive power law. If you design around contention, you can still push silly high perf (as you've shown).
FWIW I think we both agree that Postgres is not the best DB for this either :P
Do you think it would be more fair to suggest that OLTP workloads have 0% contention? That debit/credit sets never intersect?
In practice, we're seeing that our customers are already some of the largest brokerages, wealth managements or exchanges, in their jurisdictions, even national projects, and all of them with decades of Postgres etc. experience, some even running installations with 200 Postgres/MySQL machines backing their sharded core ledger.
They're not junior engineers. For example, they know about stored procedures, but the problem of concurrency runs deeper, into the storage engine itself.
At least for our customers, for the seasoned payments engineers, OLTP contention is a killer. They're tired of scaling outside the DBMS, and the complexity of expensive reconciliation systems. Several of them are even leaving their Chief Architect positions and starting TB-related startups—I know of at least 4 personally, from fintech brands you will recognize, and probably use.
I hope the spirit of our talks, trying to get the big ideas across, to make people aware of contention and Amdahl's Law, is clear, and that you take it in good faith, to the extent that we show it ourselves.