[HN Gopher] Stop using MySQL in 2026, it is not true open source
       ___________________________________________________________________
        
       Stop using MySQL in 2026, it is not true open source
        
       Author : thunderbong
       Score  : 49 points
       Date   : 2026-01-18 16:43 UTC (6 hours ago)
        
 (HTM) web link (optimizedbyotto.com)
 (TXT) w3m dump (optimizedbyotto.com)
        
       | dfajgljsldkjag wrote:
       | The author is right that usage is dropping, but that really has
       | no bearing on whether or not it is open source. Technologies get
       | replaced all the time regardless of the license they use.
        
         | gnabgib wrote:
         | Author is also being careful with the DB-Engines screen shot,
         | usage of MySQL may be dropping, but it's still number two
         | (below Oracle, above MSSQL - which shows the same curve, above
         | Postgres, far above MariaDB and SQLite) https://db-
         | engines.com/en/ranking_trend
        
           | graemep wrote:
           | The rankings methodology looks like it will favour MySQL.
           | 
           | https://db-engines.com/en/ranking_definition
           | 
           | Lots of historical mentions. Even the MariaDB website
           | mentions it. Lots of people say "MySQL" generically to
           | include its forks.
        
       | bratao wrote:
       | From my experience MariaDB is not necessarily better than MySQL.
       | The 8.x line brought many interesting features. I dream on switch
       | to Postgres, and try every year but for my use case MySQL is
       | still superior (100Bi+ rows for large texts, and heavy modified -
       | I'm also space constrained - So I need data compression and the
       | VACUUM are not good.)
       | 
       | The percona distribution is very good!
        
         | CodesInChaos wrote:
         | The storage engine is one of postgres's weakest points. I hope
         | OrioleDB will eventually give us a more robust and easier to
         | use replacement.
        
         | MrDrMcCoy wrote:
         | If space constrained and wanting compression, why not do that
         | at the filesystem or block layer if it's not supported in the
         | app?
        
         | nubinetwork wrote:
         | From my experience, mariadb is about the same as mysql...
         | depending on the queries, it can either be fine, or slow as
         | balls. I'm actually considering switching to pgsql to see if
         | its any better. /shrug
        
         | exabrial wrote:
         | Is there anything in 8.0.x/8.4.x line that isn't present in
         | MariaDb latest?
        
       | dcmatt wrote:
       | I'm not going to stop using it because it's not "true open
       | source." I'm going to stop using it because there's better
       | databases out there.
        
       | antonvs wrote:
       | Who's still using MySQL on the back end? Most Linux distributions
       | come with MariaDB. Is it Windows servers?
        
         | zinodaur wrote:
         | MySQL performs well at large scale, and has a very cool and
         | weird storage engine option called MyRocks, that slows read
         | performance but allows demented write rates and compression.
         | 
         | But yes, it is very bad.
        
         | homebrewer wrote:
         | I'm pretty sure Facebook is still running it. They've done a
         | migration to 8.0 a couple of years after it came out (it was a
         | massive release).
         | 
         | https://engineering.fb.com/2021/07/22/core-infra/mysql
        
       | logifail wrote:
       | Happily using MariaDB (as packaged with Debian) in production
       | here...
        
       | fegu wrote:
       | I used MariaDB in Azure, but got notified it was retired. Anyway,
       | migrated to sqlite.
        
       | 1over137 wrote:
       | I'm stuck on MySQL because converting to postgres is hard, the
       | tool everyone recommends (pgloader) doesn't work with current
       | MySQL (https://github.com/dimitri/pgloader/issues/782), anyone
       | know another way?
        
         | captain_coffee wrote:
         | How big of a DB are we talking about? You might need to
         | recreate the whole DB schema / structure manually from scratch
         | in PostgreSQL and then dump the data and load it in PG via
         | standard SQL file exports in the correct table order to avoid
         | failures due to FK constraints. This is a gross
         | oversimplification but you get the gist
        
           | 1over137 wrote:
           | In fact I don't get the gist :) but thanks for your reply.
           | All I know about databases is following instructions to set
           | one up as part of a LAMP/FAMP installation.
        
             | mlinster wrote:
             | Unless you use stored procedures in MySQL, recreating the
             | tables and schemas in Postgres should be straightforward.
             | Postgres now offers a 'MySQL Adapter', a.k.a. Foreign Data
             | Wrapper (https://github.com/EnterpriseDB/mysql_fdw), that
             | makes it straightforward to load data from MySQL into
             | Postgres.
             | 
             | I know you mentioned that all you know about databases is
             | following instructions, but maybe the folks at EDB or
             | Percona can give you a hand.
             | 
             | Postgres will be around for a long time, and I think it's
             | pretty obvious that MySQL won't.
        
         | homebrewer wrote:
         | It does work, I just used pgloader to migrate a 16 GB database
         | from MySQL 8.4 to PostgreSQL 18 last week (around 700 tables).
         | It's not big, but their problems seem to be with
         | authentication, not database size or functionality.
         | 
         | Have you tried it doing it yourself?
        
           | 1over137 wrote:
           | I have tried. It fails in authentication like that ticket
           | describes, so I seem to be stuck on square one.
        
       | captain_coffee wrote:
       | I would argue that the reason to stop using it is that is a
       | pretty bad piece of software to begin with, not because it's not
       | "true open source" but hey, whatever floats your boat, right?
        
       | schmookeeg wrote:
       | Oracle's icy touch. It was foretold. :D
        
       | bitbasher wrote:
       | Why would anyone use MySQL over Postgres in 2026?
        
         | timbit42 wrote:
         | Because they started with MySQL and it can be difficult to
         | switch.
        
       | exabrial wrote:
       | One does not need to stop because "its not open source", one
       | needs to switch because its no longer actively being developed.
        
       ___________________________________________________________________
       (page generated 2026-01-18 23:01 UTC)