Which one is faster: MS SQL, MySQL or PostgreSQL

​@Yuriy Zaletskyy great work, thanks for sharing!

One thing that bothers me is that on Spider chart the colors do not match colors on other charts. 

in new edition, I’ve made sure that colors match.

​@Yuriy Zaletskyy it would be great to see an updated comparison using 2026R2. I’m hoping to see improvement now that it’s fully supported.

Thanks ​@Freeman Helmuth , I will allocate some time for checking!

​@Yuriy Zaletskyy , this is great analysis and really helpful.

I am not sure about MySQL or PostgreSQL as I haven’t used it. But as you have mentioned in SQL, it is much faster in processing the request. One thing which usually comes from the customer that, the screen loads slower usually which I notice is when they have blob or images on the screen. At the same time, when multiple tabs are open with any parallel processing. This will be worth analyzing and adding to your library.

I updated my tests results just yesterday. It covers much more end to end testing, also it was done on my personal laptop. I’d be looking forward for feedback.

Thanks again for the feedback in this thread. Since my last post I have reworked how the results are shown. The measurements and verdicts are unchanged.

What's new:
• Overview as a scorecard: one row per test with each database's median and a plain label: fastest, joint fastest, "x% slower", tie or not ranked. Colour appears only where users would actually notice the difference; grey notes explain ties that look like gaps (for example "only +226 ms").
• Family charts show real values as bars starting from zero, with no more min–max whiskers or relative bars. A bar is coloured only for a noticeable difference.
• New "same-scale" versions under four of the family charts, so you can also compare sizes across tests: a 2 ms customer search no longer draws as long as a 73 ms sales order.
• Scaling chart: orders per minute and each clerk's wait for 1 to 16 clerks, with a tie or "x% slower" verdict at each step.
• Speed-up chart: 1 → 8 workers with the actual times (for example 24.1 s → 13.4 s).

​@Dmitrii Naumov  – each database now has one fixed colour on every chart (SQL Server blue, MySQL orange, PostgreSQL pink), and colour is used only where a difference is noticeable.

​@Freeman Helmuth  – the 2026 R2 results are in (build 26.200.0334; SQL Server 2025, MySQL 8.0.46, PostgreSQL 18.6; 29 tests, 6 runs each). In short:
• Users would notice a difference in 12 of the 29 tests; everything else is a tie. MySQL was noticeably slower in 11 of those 12, PostgreSQL in 7 and SQL Server in 1.
• Everyday screens: a tie on all three (largest gap 16 ms).
• PostgreSQL, now supported for production, was in the fastest group for screens, reports and multi-user order entry, and fastest at loading 10,000 records with 1 worker. It was 15% slower than SQL Server for one clerk entering orders and 30% slower for single-user invoice release.
• MySQL had 10 failed saves (deadlocks) with 4 people releasing invoices.
The R1 numbers are not directly comparable, because the tests were fixed and extended, so I can't say how much PostgreSQL itself improved.

​@KrunalDoshi  – parallel work is partly covered by the order-entry tests with 4 to 16 clerks, but screens with attachments or images and several tabs open per user are not covered yet. I've noted them as candidates for the next round.

Full results, method and the open-source scripts: https://github.com/yuriycto/AcumaticaDatabasesPerformanceAnalysis

Caveat: one laptop and unlicensed Acumatica sites (Acumatica gets about 2 processor cores), so treat this as a comparison, not a sizing guide. Feedback is very welcome.