Просмотр новости
Найдите то, что Вас интересует
Спутники
РН
SpaceX
Роскосмос
NASA
СпутникиРНSpaceXРоскосмосNASA I am fascinated by tech marketing but would be lousy at it.A common practice is to admit nothing -- my product, project, company, idea is perfect. And I get it because admitting something isn\'t perfect just provides fodder for marketing done by the other side, and that marketing is often done in bad faith.But it is harder to fix things when you don\'t acknowledge the problems. I wrote about this in 2019, this post builds on the previous post.In the MySQL community we did a good job of acknowledging problems -- sometimes too good. For a long time as an external contributor I filed many bug reports, fixed some bugs myself and then spent much time marketing open bugs that I hoped would be fixed by upstream. Upstream wasn\'t always happy about my marketing, sometimes there was much snark, but snark was required because there was a large wall between upstream and the community. I amplified the message to be heard.My take is that the MySQL community was more willing than the Postgres community to acknowledge problems. I have theories about that and I think several help to explain this:Not all criticism is validWhile I spend much time with Postgres on benchmarks I don\'t use it in production. I try to be fair and limit my feedback to things where I have sweat equity my perspective is skewed. This doesn\'t mean my feedback is wrong but my context is different. And sometimes my feedback is wrong.Bad faithSome criticism is done in bad faith. By bad faith I means that truth takes a back seat to scoring points. A frequent source of Postgres criticism is done to promote another DBMS. Recently I have seen much anti-Postgres marketing from MongoDB. I assume they encounter Postgres as competition more than they used to. Good faith gone badSometimes criticism given in good faith will be repackaged by others and used in bad faith. This happens with some of the content from my blog posts. I try to make this less likely by burying the lead in the details but it still happens.MySQL was more popular than Postgres until recently. Perhaps people didn\'t like that MySQL was getting most of the attention and admitting flaws might not help with adoption. But today the attention has shifted to Postgres so this justification should end. I still remember my amusement at a Postgres conference long ago when the speaker claimed that MySQL doesn\'t do web-scale. Also amusing was being told that Postgres didn\'t need per-page checksums because you should just use ZFS to get similar protection.Single-vendor vs communityMySQL is a single-vendor project currently owned by Oracle. At times that enables an us vs them mentality (community vs coporation). The coporation develops the product and it is often difficult for the community to contribute. So it was easy to complain about problems, because the corporation was responsible for fixing them.Postgres is developed by the community. There is no us vs them here and the community is more reluctant to criticize the product (Postgres). This is human nature and I see variants of it at work -- my work colleagues are far more willing to be critical of open-source projects we used at work than they were to be critical of the many internally developed projects.
The first rule of database fight club: admit nothing appeared first on MariaDB.org
I am fascinated by tech marketing but would be lousy at it.
A common practice is to admit nothing -- my product, project, company, idea is perfect. And I get it because admitting something isn't perfect just provides fodder for marketing done by the other side, and that marketing is often done in bad faith.
But it is harder to fix things when you don't acknowledge the problems. I wrote about this in 2019, this post builds on the previous post.
In the MySQL community we did a good job of acknowledging problems -- sometimes too good. For a long time as an external contributor I filed many bug reports, fixed some bugs myself and then spent much time marketing open bugs that I hoped would be fixed by upstream. Upstream wasn't always happy about my marketing, sometimes there was much snark, but snark was required because there was a large wall between upstream and the community. I amplified the message to be heard.
My take is that the MySQL community was more willing than the Postgres community to acknowledge problems. I have theories about that and I think several help to explain this:
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Write-heavy sysbench tests, a large server, modern Postgres and MySQL | 0 | 11.86 | 12-06-2026 |
| 2 | CPU-bound sysbench on a large server: Postgres, MySQL and MariaDB | 0 | 5.53 | 04-04-2026 |
| 3 | The insert benchmark on a small server, IO-bound workload : Postgres 19 beta1 | 0 | 14.28 | 17-06-2026 |
| 4 | The insert benchmark on a small server : Postgres 12.22 through 18.3 | 0 | 11.9 | 29-03-2026 |
| 5 | CPU-bound sysbench on a large server: Postgres 12 to 19 beta1 | 0 | 13.06 | 20-06-2026 |
| 6 | Making the PostgreSQL Documentation Even Better | 0 | 6.5 | 11-08-2026 |
| 7 | Why PostgreSQL needs an AI usage policy | 0 | 6.85 | 26-06-2026 |
| 8 | gcc vs clang for sysbench on a small server with Postgres, MySQL and MariaDB | 0 | 7.24 | 31-03-2026 |
| 9 | https://youtu.be/KaGqmF6m0rk?is=YPRyWv6NzKkLxozh Почему PostgreSQL захватил мир баз данных? / 🇱🇷СУБД / ... | 0 | 6.37 | 13-08-2026 |