• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

MySQL or PostgreSQL for high-volume high-performance database?

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    MySQL or PostgreSQL for high-volume high-performance database?

    or some other freebie database?

    discuss, or take the mick as usual, as the fancy takes you ..

    Seriously, I'd be interested in any informed opinions. They probably both have pros and cons.

    I heard the MySQL code was a monstrous hacky bag of worms internally, and the PostgreSQL code was built on much more solid foundations. But that was some years ago.
    Work in the public sector? Read the IR35 FAQ here

    #2
    Originally posted by OwlHoot View Post
    or some other freebie database?

    discuss, or take the mick as usual, as the fancy takes you ..

    Seriously, I'd be interested in any informed opinions. They probably both have pros and cons.

    I heard the MySQL code was a monstrous hacky bag of worms internally, and the PostgreSQL code was built on much more solid foundations. But that was some years ago.
    I think that's still the case. Have used both - I would use Posgresql for anything serious and MySQL if I wasn't bothered if the data ever got there. I think you're right in your assumption - PostgreSQL was ANSI 92 Compliant(?) whereas MySQL was more concerned with speed and lacked proper transaction support etc. Depends what you want but I would go Postgres almost all the time.

    Comment


      #3
      https://www.techrepublic.com/article...vs-postgresql/
      'CUK forum personality of 2011 - Winner - Yes really!!!!

      Comment


        #4
        About a decade ago I was working for a client whose databases were on PostgreSQL but were moving to a system on Oracle databases. I’m no DBA, but I spend a fair bit of time querying, inserting, updating and deleteing from tables in MS & Oracle. I’d never seen PostgreSQL before, but it only took a couple of hours to get to grips with it based on my knowledge of MS/Oracle.
        So, for me, it was similar to the big boys, and that is probably its greatest advantage and its greatest failing, the failing being that it isn’t as stripped down as MySQL.
        YMMV
        …Maybe we ain’t that young anymore

        Comment


          #5
          For raw speed MySQL.

          However, that's assuming you are not doing complex joins, transaction chains and locking strategies as that's where Postgres is superior.

          Comment


            #6
            Originally posted by TwoWolves View Post
            For raw speed MySQL.

            However, that's assuming you are not doing complex joins, transaction chains and locking strategies as that's where Postgres is superior.
            That raw speed can come at a cost though. Maybe your data gets there, maybe it doesn't ...

            Comment


              #7
              How many tables/how many records are we talking about, and how many of the tables have links between them?
              …Maybe we ain’t that young anymore

              Comment


                #8
                I have a passing knowledge, as I deal with massive datasets regularly, although not db implementations specifically. I'd take a step back and think about whether this is the right question to be asking. It depends what you mean by "high performance" (i.e. what are the performance benchmarks you need to meet?). You should look for the most robust and extensible solution that is performant, i.e. performance almost never comes first. It also depends what you're trying to model. For example, if you don't need the functionality of a relational database, NoSQL is easier to scale horizontally. However, the differences between implementations can exceed the differences between abstractions, i.e. if you don't implement something carefully, it really doesn't matter what flavour of relational or non-relational database you choose; if your relational model sucks or you implement complex joins that suck, the performance of your relational database will suck. Anyway, that's what consultants are for .

                Comment


                  #9
                  PostgreSQL+NVMe=

                  Comment


                    #10
                    One client had to move away from MySQL onto Azure MySQL because of space limitations and performance issues with standalone MySQL. Transactional queries it is fine but then again so is Azure SQL and many other databases.... I use Tableau for all my Analytics consulting and it runs a super powerful PostgreSQL behind it which I haven't seen matched by any DB.

                    Comment

                    Working...
                    X