back to article MySQL a 'pretty poor database' says departing Oracle engineer

You've collected your leaving card, novelty presents, and perhaps a bottle of wine – what's next on the list for the departing developer? For one, it's a blog rubbishing the technology he's been working on for five years. That was the choice of Steinar Gunderson, a former principal software engineer at Oracle and member of the …

  1. Warm Braw

    There is no reason not to choose Postgres

    I can think of no circumstance in which I'd choose MySQL over Postgres and very few in which Postgres wouldn't be a first choice for a new project that actually required a traditional RDBMS (it's amazing how databases get misused...).

    1. Doctor Syntax Silver badge
      Joke

      Re: There is no reason not to choose Postgres

      "it's amazing how databases get misused"

      Even Excel?

      1. Warm Braw

        Re: There is no reason not to choose Postgres

        Don't mock Excel - there's nothing like a meaningless number presented in boldface with a box around it to convince everyone your business is booming.

        1. DJV Silver badge
          Joke

          Re: There is no reason not to choose Postgres

          Yeah, but my number is better than your number cos I added 1 to it! (And probably made the font size bigger, so there!)

          1. Anonymous Coward
            Anonymous Coward

            Re: There is no reason not to choose Postgres

            Don't forget the pretty colors!

        2. mpi Silver badge

          Re: There is no reason not to choose Postgres

          3 words:

          Pastel Background Colors

          3 more words:

          Comic Sans MS

      2. Anonymous Coward
        Anonymous Coward

        Re: There is no reason not to choose Postgres

        You're joking, but I wish it wasn't so.

        Students get taught how to abuse Excel to munch large amounts of analytical results, whereas I have started to wonder if it wasn't better to teach them a less proprietary means with more flexibility. Surely the larger the data set, the more efficient it becomes to process that with a decent database like Postgres? Why not teach them something less locked in? Or is this what we are deliberately aiming for: dependency on a single tool that is not even adequate for the job?

        Oh, wait, that's exactly it.

        1. Anonymous Coward
          Anonymous Coward

          Re: There is no reason not to choose Postgres

          Unstructured analytics are exactly what tools like spreadsheets were designed for. RDBMS is the wrong tool for unstructured analytics, no matter what the data set. An object store database is a better fit, which allows arbitrary slots to be defined per-object rather than just per-class.

          There is no "one size fits all" tool for data stores. After 30+ years of beating myself senseless on the cases and monitors and keyboards of these beasts, I've worked with more ways of storing data than I care to remember. Ditto transmitting data, collating data, calculating data, and summarizing data.

          I know from instinct and experience which approach I want to take for a problem given the scale of its data set, but even that can become misleading as soon as someone says "we want to take it to the cloud."

          1. Anonymous Coward
            Anonymous Coward

            Re: There is no reason not to choose Postgres

            Thank you, that is a sensible answer.

            Still, I am concerned about FAR too many proprietary tie ins in education because it impairs exactly that flexibility we need to solve problems that may lie outside the bounds of the tools we presently use. But maybe that's just me..

            1. phuzz Silver badge

              Re: There is no reason not to choose Postgres

              Pretty much all the other spreadsheet programs, and the online ones, work in the same way as Excel, so you're not exactly 'locked in' to only using Excel if that's what you were taught Any more than someone being locked in to only using Libre Office if that was what they were taught with.

          2. mpi Silver badge

            Re: There is no reason not to choose Postgres

            >Unstructured analytics are exactly what tools like spreadsheets were designed for.

            True, but there is no need for this spreadsheet being a proprietary product in a format that is hard to read, hard to write and hard to use with anything but said proprietary software.

            1. phuzz Silver badge

              Re: There is no reason not to choose Postgres

              I can't remember the last time I had any trouble opening an Excel file in any other program.

              (.xlsx as well)

          3. anothercynic Silver badge

            Re: There is no reason not to choose Postgres

            I find myself wrangling both Postgres and Excel to get the information I need, although I'm starting to find myself adding some of the functionality that Excel gives us to Postgres (as queries) that do away with formulae that are a mess to handle in Excel.

            1. katrinab Silver badge
              Meh

              Re: There is no reason not to choose Postgres

              I am using MongoDB for a project that has semi-structured data. But with 24m records, it is waaaaaay above the limits that Excel can cope with.

              It is also a lot faster. With 500k records, Excel took about 6 hours to do the calculations. Mongo took less than a second once it was indexed correctly, a couple of minutes if it is not.

              1. Charlie Clark Silver badge

                Re: There is no reason not to choose Postgres

                FDW and Postgres. Job done.

          4. Anonymous Coward
            Anonymous Coward

            Re: There is no reason not to choose Postgres

            > Unstructured analytics are exactly what tools like spreadsheets were designed for.

            R

            (The language, not the letter)

            1. Yet Another Anonymous coward Silver badge

              Re: There is no reason not to choose Postgres

              R. (The language, not the letter)

              The correct answer is AWK

              1. Munchausen's proxy
                Pint

                Re: There is no reason not to choose Postgres

                "R. (The language, not the letter)

                The correct answer is AWK"

                Why not both? The combination of subsetting and selection in AWK followed by fancy stats and pictures in RStudio seems very powerful in my somewhat limited experience.

                1. Yet Another Anonymous coward Silver badge

                  Re: There is no reason not to choose Postgres

                  The obvious answer would be:

                  “Whenever faced with a problem, some people say `Lets use AWK.'

                  Now, they have two problems.” -- D. Tilbrook

        2. Gordon 10
          Mushroom

          Re: There is no reason not to choose Postgres

          "better to teach them a less proprietary means with more flexibility"

          Whoooshh. Thats the sound of reason people use Excel flying over your head.

          Excel is a shit database. Excel is a shit analytics tool. Excel is a shit reporting tool.

          HOWEVER - its mediocre enough in the sweet spot between all three and its UX is intuitive enough that its good enough for about 75% of the use cases its used for.

          There's a reason that if Excel was ever globally hacked/corrupted EVERY SINGLE Corporate out there would go out of business, and that is for 75% of use cases for non-IT literate people its GOOD ENOUGH.

          Heareth endeth the lesson and the SHOUTING.

          1. Anonymous Coward
            Anonymous Coward

            Re: There is no reason not to choose Postgres

            I suspect you just gave a whole gaggle of criminals their next target :(

            1. veti Silver badge

              Re: There is no reason not to choose Postgres

              Excel is also a distributed target. Even if you could hack all instances of a single version - in itself, not something that has ever been demonstrated even conceptually - you'd still only hit a minority of global spreadsheets currently in use.

          2. Anonymous Coward
            Anonymous Coward

            Re: There is no reason not to choose Postgres

            Personally I like the shouty bits.

            -- Vogon Guard

          3. Anonymous Coward
            Anonymous Coward

            Re: There is no reason not to choose Postgres

            Lotus Improv was a brilliant re-invention of the spreadsheet. I bought it and absolutely loved it. Unfortunately, it was too different to previous spreadsheet products that people had become used to. Not enough people were willing to learn a new tool, even if it was vastly superior. Poor sales led to it being killed off.

            I have been messing with spreadsheets since VisiCalc on the TRS 80 and have used various versions of most of the major spreadsheet products since. None could touch Improv once you got your head round the way it did things.

            I keep meaning to have a look at Quantrix Modeler to see how it compares.

            1. katrinab Silver badge
              Meh

              Re: There is no reason not to choose Postgres

              You can get Improv-like functionality if you use Tables in Excel.

              Not as good, but it does at least run on modern hardware.

          4. Anonymous Coward
            Anonymous Coward

            Re: There is no reason not to choose Postgres

            Have you been taking writing style lessons from Bob?

          5. Anonymous Coward
            Anonymous Coward

            Re: There is no reason not to choose Postgres

            Well shouted. The other important point is that MOST PEOPLE In BUSINESS who use NUMBERS are not (AND DON’T WANT TO BE) what is vaguely and usually POMPOUSLY defined as IT-literate. They just want the tools they use to be simple to learn and very widely available so that when they move jobs they can still ADD UP the way they have already learned.

            1. Anonymous Coward
              Anonymous Coward

              Re: There is no reason not to choose Postgres

              Here is a function you can use if you can't be bothered to randomly capitalise the words yourself.

              https://github.com/ScottKnights/Misc/blob/main/bobify-text.ps1

            2. Anonymous Coward
              Anonymous Coward

              Re: There is no reason not to choose Postgres

              #getshitdone

          6. herbgold

            Re: There is no reason not to choose Postgres

            "Excel is a shit database." No, it's not. Excel is not a database.

            1. Primus Secundus Tertius

              Re: There is no reason not to choose Postgres

              I have used Excel and Libre Office Calc for many simple, but small, databases. Membership lists of voluntary bodies, for example. It is useful to have that functionality as well as accounting and mathematical uses.

            2. Calum Morrison

              Re: There is no reason not to choose Postgres

              You completely failed to process the joke. Were you querying it in Excel?

              1. Version 1.0 Silver badge
                Joke

                Re: There is no reason not to choose Postgres

                He was probably writing his post in Excel.

                1. Calum Morrison

                  Re: There is no reason not to choose Postgres

                  Doubt it; he sounds like an Access fanboi.

                  1. J27

                    Re: There is no reason not to choose Postgres

                    You're triggering my PTSD!

          7. Wormy

            Re: There is no reason not to choose Postgres

            Even for people who are very IT-literate, there are some things Excel does better than any other commonly available software. One example is where you need both semi-pretty representation of data for human consumption, and a lot of tie-ins with data that isn't so human readable.

            For relatively simple cases, I can do that in Excel in a few minutes, and send it to other people who generally can open and use it with no problem.

            If I build it using a true database, I either have to have that database hosted somewhere, or make people install extra software. That's a HUGE impediment to rapid information sharing.

            Excel also makes for a very convenient way to quickly mock up what you think you might want in a database, and pass it along to the devs to implement.

            It's true, it's relatively terrible at a lot of things - it's slow, it's cumbersome, it's missing a lot of features that would make it much more useful. But, for a lot of things, it's still the quick/easy/dirty way to do something when you don't have time for development work.

          8. ibmalone

            Re: There is no reason not to choose Postgres

            A friend in university teaching is increasingly trying to teach students to use Python for data analysis (specifically Pandas with some matplotlib). Structured data, but separation of data and code, ability to do arbitrary things and combine in other data sources if you need to. Maybe fewer 3D bar charts and such, that's not necessarily a bad thing. Excel is still a useful viewer to load up the tables. Personally I'll use R for preference when it comes to data analysis, but if Python (or Perl, or Awk, or C, or, Lord help us, PHP) is more appropriate then that's what comes out of the box. Science students, but for finance they recruit graduates too right? Surely can't be long before those departments also catch on that they're meant to be teaching quantitative analysis and it's 2021+.

            About the only thing Excel still gets used for here is calculating trip expenses with friends, and it's great for that, mainly because it makes the data input easier and who can be bothered setting up an actual database for it?

            1. Mark 65

              Re: There is no reason not to choose Postgres

              The biggest impediment on those two vs Excel is recreating the environment. For the basic stuff an earlier poster eluded to, Excel is good enough for most.

              1. Glen Turner 666

                Re: There is no reason not to choose Postgres

                "The biggest impediment on those two vs Excel is recreating the environment"

                Have a look at Juypter Notebook. It's a cloud-hosted web presentation of Python, R and other languages in a "engineering notebook" style. To recreate the environment you just log into the page again. It's excellent for a quick analysis, since if you have to return to the analysis later then the data exploration you did is presented in a narrative, making it easy to track what you were thinking at all those months ago.

                Juypter has very quickly become the weapon of choice for analyzing science data.

                1. ibmalone

                  Re: There is no reason not to choose Postgres

                  Jupyter doesn't even need to be cloud-hosted, you can run and keep your notebooks locally, runs a local server on your desktop that you interface with through your browser. Install on windows using Anaconda Navigator, which will come with most of the standard data handling libraries.

    2. Anonymous Coward
      Anonymous Coward

      Re: There is no reason not to choose Postgres

      There are several reasons to avoid both MySQL and Postgres - both are good as datadumps for simple things like websites and simple applications - when you need real databases there are far better choices, even if you have to pay for them.

      1. Anonymous Coward
        Anonymous Coward

        Re: There is no reason not to choose Postgres

        Which ones? Oracle? DB2?

        Just curious.

        1. Fruit and Nutcase Silver badge
          Joke

          Re: There is no reason not to choose Postgres

          Oracle? DB2?

          With both of these, part of the total cost (to you) is the cost to these vendors of keeping an army of lawyers and bean counters on the payroll to clawback/avoid paying the commissions for their sales people.

          1. Anonymous Coward
            Anonymous Coward

            Re: There is no reason not to choose Postgres

            If only you would have said "With both of these, part of the total cost (to you) is the cost to these vendors of keeping an army of lawyers to audit you and fine you for not unchecking a box that was checked by default", then you wouldn't have had to use the joke icon!

            1. Fruit and Nutcase Silver badge

              Re: There is no reason not to choose Postgres

              A fair, nay, an important point. Thanks.

              Also, with the former, $$$ is needed to supply Larry's racing yacht habbit, and with the latter, choppers for Ginny

      2. PassiveSmoking

        Re: There is no reason not to choose Postgres

        Only somebody who doesn't really understand RDBMSes could possibly make a statement so asinine. Postgres is a fine product, and there's very little you can't do with it if you understand that the RDBMS paradigm is great for the stuff it's designed for.

        If you're working with data that isn't well-managed with an RDBMS then I agree, Postgres isn't a great choice. But neither is any other RDBMS, including paid ones like Oracle's offerings that aren't MySQL

        I did never care much for MySQL though. It frustrates me that it's so widespread when the far superior Postgree is every bit as open source and far more capable.

      3. Plest Silver badge
        Mushroom

        Re: There is no reason not to choose Postgres

        Can we assume you're one of those devs who simply sees a DB, especially RDBMS, as a dirty data black hole? Thus it's everyone else's problem to worry about why your SQL code, that you scraped off Stackoverflow, will be dumped on some poor backroom DBA to tune up to make your app even remotely functional.

        If you feel that way, head back to your cloud data stores and leave the real databases to real techies.

        1. Version 1.0 Silver badge

          Re: There is no reason not to choose Postgres

          I remember using dBase ... yes, there was a dirty black hole in the middle of the 8" floppy disk.

          1. bombastic bob Silver badge
            Unhappy

            Re: There is no reason not to choose Postgres

            dBase - the first and the WORST!

            Clipper, at least, was compilable into something that could interface with C. So for some stuff it almost made sense... except it did not do SQL and STILL stored numbers in the tables as FREAKING TEXT.

            I'm glad it all just faded away...

        2. David Halko

          Re: There is no reason not to choose Postgres

          >> it's everyone else's problem to worry about why your SQL code, that you scraped off...

          Isn't that the truth!

          A small percentage of App Developers understand indexes & reasonable construction of SQL code.

          It is practically a sin to pawn off to a DB to a DBA for anything outside of: backup, restore, and projecting performance on larger/smaller OS / H/W footprints.

          I preferred encouraging our team to work on a small development box, to force developers to experience memory & CPU constraints, before placing code into production with much higher workloads & data quantities.

          1. Number6

            Re: There is no reason not to choose Postgres

            If only MS had done that with its Windows developers...

    3. Anonymous Coward
      Anonymous Coward

      Re: There is no reason not to choose Postgres

      There's only one thing that "MySQL" has going for it: Galera Cluster. If Galera supported PgSQL, then it would honestly be game over. Sadly, PgSQL has no clustering that's even close to Galera. There's been a few attempts at something similar, but each one has died.

    4. anothercynic Silver badge

      Re: There is no reason not to choose Postgres

      Same. Postgres for the win.

      :-)

      1. AMBxx Silver badge

        Re: There is no reason not to choose Postgres

        I'm a fairly recent convert to Postgres, though I've been aware of it for years. Most of my work is in MS SQL with bits in MySQL.

        What's surprised me is how Postgres views Oracle as their target, not MySQL.

        I just wish that when I created a view that Postgres would keep my definition with all its comments.

        Don't get me started on not being able to modify a view because of dependencies. Drives me nuts.

        1. FIA Silver badge

          Re: There is no reason not to choose Postgres

          Having used both I'd tend to gravitate towards MySQL, but that's because I find the syntax a little easier to work with than postgres, which I find tries to be a little too Oracle like. (Oracle's SQL dialect still gives me nightmares).

          I liked being able to define variables without having to write a stored procedure; I also found the MySQL tooling a bit nicer (although they're both fucking awful).

          For the use cases both were performant for the workloads they were being used for.

          My first job used Sybase, now that's a database I do have fond memories of.

        2. Charlie Clark Silver badge

          Re: There is no reason not to choose Postgres

          What's surprised me is how Postgres views Oracle as their target, not MySQL.

          Postgres is older than MySQL and has always done things like ACID that MySQL has only recently been able to do properly. MySQL became popular quickly because it had great write speed and the developers understood the need for good Windows tooling: I've run Postgres on Windows with cygwin and while it worked, it wasn't likely to win many fans.

          But there was never much money on the MySQL space because the reasons why it was fast were also why it was completely unsuitable for the business world, where data integrity and support for transactions were essential. To be fair, this wasn't what MySQL was developed for, but that didn't stop thousands of people finding out the hard way.

          But software development, and particularly software quality and handling bug reports, was always awful. And this was something that improved almost immediately after Oracle took over: personally, I remember a bug report I'd submitted more than 10 years previously suddenly got notice. And there's no doubt that in the last few years, Oracle has improved the engineering and release management. But, in the open source world they're caught between a rock and a hard place: the "never Oracle" zealots who use MariaDB, precisely because it is the non-Oracle fork, and the rest of the world that finds Postgres gets it right most of the time, continues to get better (more features and better performance), and plays nicely with the inevitable existing proprietary databases such as Oracle or DB2.

    5. Geez Money

      Re: There is no reason not to choose Postgres

      I'm so glad this is the first comment. I've heard this so many times (and every project I spec goes this way) that it's entirely 'meh' to me. Postgres is a rock solid database thanks to the core philosophy of only doing things once they can do them right, with some pretty amazing extensions (PostGIS comes to mind) built on top of that. MySQL tried to ram as many features in as possible from day one, does them all pretty poorly and hasn't really been able to expand its featureset as much over the decades because they didn't take the time and care in crafting that postgres team did. It's worse at everything. Don't use it.

    6. Anonymous Coward
      Anonymous Coward

      Re: There is no reason not to choose Postgres

      I use mongodb for everything because it has webscale.

    7. Tom 7

      Re: There is no reason not to choose Postgres

      I use a lot of OO methodology when developing databases. I do all object access through Stored Procedures so I can change the code that access it or the database structure independently - with security setups this also prevents Web access fucking with your DB - no SQL can be run by the web user. Postgres procedure overloading can be a bit of a pain in the arse when doing this so I frequently do early development on MariaDB but that's probably because I haven't RTFM for postgres thoroughly enough to find a workaround there. But dumping the MariaDB to sql and loading it Postgres is normally pretty quick.

      1. Charlie Clark Silver badge

        Re: There is no reason not to choose Postgres

        Sounds like an interesting approach, got a link for some examples?

        Postgres will let you send the stored procedures over the wire, which makes keeping your server and client code in the same repository easy. Hannu Krosing demonstrated this in Python a while back, where he used a decorator for code that was to run on the server. Must say, I thought this was pretty neat but have not yet got round to trying it myself.

  2. Greybearded old scrote
    Unhappy

    Captain Obvious

    I've been muttering "I can haz Postgres?" for about 20 years. Ever since I found out that MySQL 3.x didn't do the transactions I was taught in my introductory level course. Or views.

    Yes I know it has both now, but I keep tripping over more stuff that they couldn't be arsed to do right. The utf8/utf8_mb4 entertainment is a doozy, especially when you find that VARCHARS are actually VARBYTES.

    The joke's on me though. Not only have I never found an employer where I could make the transition, the current $JOB has an even worse excuse for a dbms.

    1. jabuzz

      Re: Captain Obvious

      Remember when Postgres didn't do SQL then? Want to know why MySQL is so popular? The answer is simple at the time there where three options for a database on Linux. mSQL which was not free the application using it was not opensource. Postgres which was a great database but the query language was not SQL, and finally MySQL which was GPL and the query language was SQL.

      By the time Postgres was fitted with an SQL query engine it was too late and MySQL had the mind share. If you don't this history then get off my lawn.

      1. Anonymous Coward
        Boffin

        Re: Captain Obvious

        > Postgres which was a great database but the query language was not SQL, and finally MySQL which was GPL and the query language was SQL.

        > If you don't this history then get off my lawn.

        I'm going to shit on your lawn.

        For a whole *one year* in 1996 MySQL had a rubbish product with no atomic transactions but a SQL syntax, while Postgres was a full-fledged product that favoured the far superior Quel. Thereafter it went SQL - necessary to get market share from sheep who only knew the mantra Oracle = SQL therefore SQL = good. Besides Postgres was developed by some random bloke called Stonebraker and what would a Turing Award winner know about databases?

        1. eldakka

          Re: Captain Obvious

          > while Postgres was a full-fledged product that favoured the far superior Quel.

          That's a "you're holding it wrong"-type argument.

          If the majority of users want SQL, and don't want to use Quel, then you either need to support SQL, or become at-best a niche product.

          Customers decide on what features they prioritize and choose products based on that. Most companies/products aren't in the priveleged Apple (or Model T "you can have any colour you want as long as it's black") place of being able to dictate to customers.

          1. Charlie Clark Silver badge

            Re: Captain Obvious

            SQL has a long history of being knobbled by various vendors, who then implement their own versions of it, to ensure lock in, while being used by the marketing departments as argument for it. The criticisms of it, both for data definition and querying, are long-standing and still valid.

        2. Peter Gathercole Silver badge

          Re: Captain Obvious

          Agree. Quel was pretty mature even before Postgres, it being the query language for the original Ingres that came with BSD tapes (not sure about later ones, but it was definitely on the BSD 2.x tapes). I used it in 1979.

          I've had arguments about how long SQL has been around. Most people talk about SEQUEL (Structured English QUery Language) from IBM from the mid '70s, but Ingres was the first RDBMS available under a permissive license.

          Apparantly, the name SQL came about because SEQUEL was already trademarked, and Structured Query Language became a backonym.

        3. Ben Tasker

          Re: Captain Obvious

          > For a whole *one year* in 1996 MySQL had a rubbish product with no atomic transactions but a SQL syntax, while Postgres was a full-fledged product that favoured the far superior Quel.

          You've not so much shat on his lawn as re-stated what he said.

          MySQL had a market advantage for a full year and won the mindshare. It doesn't matter whether Quel was the superior solution, what matters is what the market wanted: SQL.

          It's no different to Betamax/VHS, Blu-Ray/HD-DVD: it doesn't _really_ matter which is technically superior, what matters is what the market goes with. If you choose right, then you get an early leader advantage and can make it very, very hard for competitors to catch up, let alone overtake.

          > Thereafter it went SQL - necessary to get market share from sheep who only knew the mantra Oracle = SQL therefore SQL = good

          Or to phrase it another way - it went SQL because that was the only way to stay relevant/increase usage.

          You can make hundreds of arguments over how Quel should've won out, and I'd likely agree with you, but the only thing that matters is which was chosen by the userbase.

          1. tiggity Silver badge

            Re: Captain Obvious

            Indeed never underestimate the effects of market "need" (or inertia)

            Inertia exposed as an e.g. (IMHO, though also due to a lack of decent SPARQL libraries for some languages) in lack of takeup of SPARQL endpoints as lots of devs who are low on time see its yet another query language and CBA (e.g. they already have had to deal with queries via SQL, GraphQL, XQuery etc. and at some point decide they want a break from learning yet another similar but irritatingly different syntax), even though SPARQL is a good query language for accessing RDF

          2. Anonymous Coward
            Anonymous Coward

            Re: Captain Obvious

            > It's no different to [..] Blu-Ray/HD-DVD [..] what matters is what the market goes with.

            In the Blu-Ray/HD-DVD case, though, the "market" didn't really decide. That was essentially decided by the content industry when they came down on the side of Blu-Ray.

            Sony essentially forced the hand of the rest of the content industry- keen to enjoy a repeat of the lucrative success DVD had turned out to be- when they implied that the market would remain in limbo and stagnant so long as there were two rival formats. (It was obvious back then that there was only going to be one winner, and consumers wouldn't want to risk getting stranded with the next "Betamax".)

            And it almost certainly wasn't going to be HD-DVD, so it made sense to bite the bullet sooner rather than later.

        4. mtrantalainen

          Re: Captain Obvious

          MySQL got traction because it was easy to maintain for cheap shared environment hosting. Those services were always totally unsafe so using a database with no support for transactions wasn't too big a problem over all the other problems.

          Still around year 2000 maintaining a single host with multiple users with shell access and trying to sell them SQL service was easier with MySQL. As a result, every installable web service supported MySQL or didn't succeed.

          Another problem with PostgreSQL was (and still is) that all the config defaults are really bad. Memory usage is still optimized for servers with 32-64 MB (not a typo!) of RAM. As a result, the performance leaves a lot on the table if nobody tweaks the config to match the hardware.

      2. cdegroot

        Re: Captain Obvious

        To be honest, Postgres was a long time ago before it became PostgreSQL. I was sad, I loved postquel.

      3. Greybearded old scrote

        Re: Captain Obvious

        That's pretty ancient history given that I wrote about a 20 year span. Relevant now? Not so much.

        I see the problem as being most people didn't learn the fundamentals first, so they don't understand what's wrong with MySQL. Or Access.

        1. katrinab Silver badge
          Meh

          Re: Captain Obvious

          Does anyone still use Access? Microsoft seem to have abandoned it.

          1. Greybearded old scrote

            Re: Captain Obvious

            I'm out of the loop on MS Office, so I wasn't aware of that. I wouldn't bet much on there being nobody relying on it still.

            1. Anonymous Coward
              Anonymous Coward

              Re: Captain Obvious

              Ok. Anonymous head above the parapet here. Of course we still use Access. Not to handle the important big corporate stuff, because that's on a server and tied up in pretty bows by the DBAs. But as a component in the tool box. Use it as a front end GUI that actually works for human beings. Rustle up some useful views. Write a report that looks professional. Take a load of messed up spreadsheet data and clean it up, sort out the weird dates, resolve the random units and check the spelling before it gets put into the 'proper' database.

              And I know there's 'better' GUI tools, and 'better' query tools and 'better' reporting tools - but Access is actually quite a nice Swiss Army knife of a tool. You wouldn't use it to disassemble a solar panel on the ISS, but you are glad it's in your pocket when your horse gets a stone in its hoof.

              1. Down not across

                Re: Captain Obvious

                Access is evil as front end. It (possibly depending on backend) seems to have a habit of locking tables at backend effectively locking all other users out.

                (or at least used to, when I last encountered end users using it as front end 10+ years ago...)

          2. hammarbtyp

            Re: Captain Obvious

            Access is still used in a lot of backend for windows applications, especially those using MFC

            Unfortunately this means keeping those apps up to date is a real pain

            1. SloppyJesse

              Re: Captain Obvious

              > Access is still used in a lot of backend for windows applications

              Access? or Jet?

              I still see the Jet engine used a lot behind the scenes (Has MS Exchange moved away from it now?)

              Access as a GUI into 'real' databases for users that need to dig further/more flexibly into details than simple canned reports allow.

              1. Kristian Walsh

                Re: Captain Obvious

                Jet is a decent solution for an application’s private, persistent storage. Basically for most things on Windows where you’d consider Sqlite, Jet gives you more features, better locking safety and better performance.

                The exception is where you need to run on multiple platforms, or you want to use those db files as your application’s file-format, in which case, it’s Sqlite every time.

          3. bombastic bob Silver badge
            Devil

            Re: Captain Obvious

            Micros~1 has another analysis product that's part of 'Office 364' (the name of which I cannot recall) so why do they need 'Excess' any more, right?

            I have seen (and played with) Libre's "Base" and it seems kind of primitive but does a lot of what I used to do wtih Excess a couple of decades or so ago...

            But as for MySQL and its quirks (example: for embedding a single quote in a text column, MySQL breaks the rules established by the SQL standard) I had a HELL of a time setting it up. And like it has been mentioned in the article, setting up PostgreSQL is pretty simple. In fact i did it last week to create a test database for adding new tables, etc. and a web-based UI to query things. Needed a test database so I did not disturb the production one. And the production one is actually on a USB drive plugged into an RPi 3b+. (it analyzes final testing phase of a piece of equipment that goes through a rigorous test, with various things tracked like serial numbers, any repairs that were done, test results, and so on and a cron-activate script sends a ZIP file of psql output every weeknight to someone to be imported into that Micros~1 thing I could not remember the name of).

            1. katrinab Silver badge

              Re: Captain Obvious

              You are probably thinking of PowerBI?

      4. DrXym

        Re: Captain Obvious

        I think it was more to do with LAMP web development (Linux, Apache, MySQL, PHP). MySQL sucked for SQL but it was good enough for basic queries and read operations and it succeeded.

        But it was always a cobbled together broken database which went through a succession of backend engines trying to approach what a SQL database should be. Postgres was more or less it from the moment it supported SQL.

        Personally if I were developing SQL based apps I'd prefer PostgreSQL for the sake of correctness, knowing that if there are problems they're probably on my side, not the database's.

    2. Anonymous Coward
      Anonymous Coward

      Re: Captain Obvious

      At one point MySQL didn't even do sub-queries which after 20 years of Oracle really freaked me out! Having to long form and procedurally code stacks of SQL was such a pain, that put me off ever dealing with MySQL again.

      I can only assume Larry knew MySQL would sell out to him while Postgress would tell him and his yaughting mates where to go!

  3. beekir

    Moved to MariaDB

    I switched jobs about two years ago to work with MariaDB and I can't overstate how primitive it is. Not even DB2 running on an AS/400 is as incapable or incomplete as this mess. Don't ever trust your business to this DB platform, it's a total disaster.

    1. alain williams Silver badge

      Re: Moved to MariaDB

      It might be primitive but for many people it is good enough - that is important.

      It is also simple enough to get started quickly.

      Once people have got used to it why move from something that you have learned ?

      1. Greybearded old scrote
        Trollface

        Re: Moved to MariaDB

        Bitter experience. Are you a Win user perhaps?

        (OK, I'll own up to the icon.)

      2. Lennart Sorensen

        Re: Moved to MariaDB

        But so is postgres, in fact I would say it is even easier to get started with and it works better. So there is no reason to use mysql at all. Except of course for the fact so many other projects insist on you using it as the backend unfortunately.

        1. Anonymous Coward
          Anonymous Coward

          Re: Moved to MariaDB

          It's also a default for most scripted CMS installs. I have as yet to see any with Postgres. I assume this tends to fulfil the "good enough" criteria.

          1. Charlie Clark Silver badge

            Re: Moved to MariaDB

            Have you looked at the schema of things like WordPress? An utter fucking nightmare, no wonder they get hacked all the time.

      3. rcxb1

        Re: Moved to MariaDB

        > for many people it is good enough

        For many people, a hammer is a good enough screwdriver.

        > It is also simple enough to get started quickly.

        PostgreSQL is just as simple to get started with.

        > Once people have got used to it why move from something that you have learned ?

        Umm... performance, stability, scalability, features, bugs. You know, pretty much every reason someone moves from one piece of software to another.

        1. eldakka

          Re: Moved to MariaDB

          > Umm... performance, stability, scalability, features, bugs. You know, pretty much every reason someone moves from one piece of software to another.

          Nice way to totally not get the argument.

          "Good enough" for what they are doing means those things are not an issue.

          If I already have MySQL for my tin-pot project and never have had an issue, why would I move? Sure, I completely accept that Postgres is a 'better' DBMS, but if all the things it is better at are completely irrelevant to my project, why would I move to it - and note, moving implies you already have something working, therefore why expend the effort for, literally, nothing. You gain nothing by moving the existing implementation? Why spend money to make such a migration (even if it's not cash money, it could be opportunity cost)?

          If I already know MySQL, then MySQL is easier to get started with than Postgres, because I don't have to go to the (possibly trivial, but trivial != 0 effort) effort of working out how to do something I already know in Postgres for no gain if MySQL is good enough, or hell a CSV and awk/sed might be good enough, and quicker, even if bodgy, if I know how to whip up a report in 2 or 3 minutes versus taking a day to learn how to set up a database, ingest the data, query the data, format it and print it out.

          Don't let 'perfect' be the enemy of good enough. Good enough is precisely that, good enough.

          If I need to write a quick reminder note, notepad is good enough, I don't need to fire up a full-on word processor and load a template, format text, then import it into a desktop publishing app for a really awsome professional look, etc. for a quick reminder note.

          1. FIA Silver badge

            Re: Moved to MariaDB

            Don't let 'perfect' be the enemy of good enough. Good enough is precisely that, good enough.

            Hey kids, learn this lesson, and learn it well. It will make your life much much much easier.

            Or to put it another way, with limited resources, focus on fixing/changing the things that matter, not the things you just simply don't like.

          2. yetanotheraoc Silver badge

            Re: Moved to MariaDB

            "If I already know MySQL, then MySQL is easier to get started with than Postgres, ..."

            As I am sure you know, the danger there is in using MySQL on a new project even when Postgres *is* the better solution -- which you could only find out by learning a little Postgres.

            When I were a lad, I enjoyed taking things apart to see how they worked. (And my mom did *not* enjoy shrieking at me "Put that back together NOW!") I didn't do it to gain useful knowledge, _however_ despite that the knowledge very often did prove useful. And now I do _useless_ tinkering with software that very often does prove useful later.

            "Don't let 'perfect' be the enemy of good enough."

            I counter that with: Be a lifelong learner.

            1. eldakka

              Re: Moved to MariaDB

              > When I were a lad, I enjoyed taking things apart to see how they worked.

              > I counter that with: Be a lifelong learner.

              When I was a lad, I too enjoyed tinkering with that sort of thing. And I enjoy learning things.

              But I am no longer a lad. I get paid money to do this stuff. Someone has to pay money to someone to get it done. Even if it's not cash money, it's opportunity cost. I could spend all day working out how to do it with product B, or spend an hour getting it done with product A, and go spend that 6 hours I've saved with my family, friends, hobbies, or just getting pissed, which are more valuable to me than unnecessarily wrangling with something for several hours. In this opportunity cost model, my family/friends/hobbies/teammates/pub are the ones who have to pay the cost of me learning this other unnecessary product instead of spending the time with them.

              I get paid for results, not tinkering. The longer I take to get something done, the costlier it's going to get, someone has to pay that, and if its a consumer-facing project, the consumer will have to pay more.

              Time is cost, and I value my time spent doing non-IT related activities (the aforementioned time with family, friends, non-IT hobbies) higher than the value of spending those hours learning product B if product A is good enough for the job. If product A is not good enough, then, and only then, will the value proposition have changed to make learning product B (or C, D, ...) worthwhile, at which point - since I've judged it's value to me appropriate - I'll be happy as a pig in shit learning it.

      4. katrinab Silver badge
        Meh

        Re: Moved to MariaDB

        People go with "good enough", because there is some advantage to it which offsets the disadvantages.

        Cost is often one advantage, but it "costs" the same to pkg install or apt install both of them.

        Excel is "good enough" if you have about 100 records you want to analyse or chart, and it is a use-once scenario so there's no concerns about future maintenance of the spreadsheet. And the advantage there is that it is a lot quicker to set it up.

        What is the advantage of MySQL over Postgres?

        Recently I set up Nextcloud on a new deployment. I had a choice between MySQL and Postgres. Postgres was actually slightly easier to set up than MySQL, but the difference was very marginal, it was basically the same steps required for both.

    2. Aitor 1

      Re: Moved to MariaDB

      Is it primitive? Yeah.

      But also runs on anything.

      For a small ddbb a few reports, etc, it is fine.

  4. boblongii

    Reality is a vampire - it both bites and sucks

    "This DB is much better than MySQL; there's effectively no chance of data loss."

    "Will it handle <insert current insane level of demand from web here> requests per second on our hardware?"

    "Well, no, but if MySQL goes down while handling that you're going to have a mess."

    "This is web-stuff, not controlling a nuclear power plant. We can restore from last night's backup then. Transaction speed is the thing."

    "But you can't just not worry about losing data!"

    "The danger is the chance of losing data times the value of the data. For us, *both* those numbers are very low even with MySQL, so we can worry about it less than having the whole system go down because it can't keep up."

    "Sigh."

    1. Anonymous Coward
      Anonymous Coward

      Re: Reality is a vampire - it both bites and sucks

      So you just want to disable data safety for speed? You can do a lot of that with PgSQL, but it sounds like you're using the wrong tool for the job, honestly. Something like KeyDB might be the answer (I was going to say MongoDB and use the "MongoDB is Web Scale" YouTube video, but some other bastard managed to beat me to it).

      1. david 12 Silver badge

        Re: Reality is a vampire - it both bites and sucks

        Yes, and that's why MySQL became the default web stack. Effectively a read-only database system. Originally, that was both its great strength and great weakness.

    2. Tim99 Silver badge
      Joke

      Re: Reality is a vampire - it both bites and sucks

      For data integrity use SQL DDL/DCL/TCL - For fast, use > /dev/null

  5. Robigus
    Joke

    Nuts to them all. MongoDB is web scale.

    Why not MongoDB? It's web scale : https://www.youtube.com/watch?v=b2F-DItXtZs

    1. Greybearded old scrote
      Coat

      Re: Nuts to them all. MongoDB is web scale.

      I see you're joking, but...

      Just in case anybody still means it.

    2. swm

      Re: Nuts to them all. MongoDB is web scale.

      I like SQLite with sqlite-jdbc for interfacing with java. Let the downvotes begin...

      1. Greybearded old scrote

        Re: Nuts to them all. MongoDB is web scale.

        I agree, with qualifications.

        For use cases that have very many more reads than writes it's an excellent choice. If a lot of inserts and updates are needed then everyone gets to wait. I've been bitten by that one.

        The other problem is that it ignores the extremely useful type constraints, everything is a string. There's an argument that if you are using a dynamically typed language (Perl, Python, Ruby PHP, nothing really common) then that might even be a better fit.

      2. Tim99 Silver badge

        Re: Nuts to them all. MongoDB is web scale.

        I’m old, so I used SQLite with bash, C, and Python. I found it particularly useful when "tidying up" CSV data that I generated from luser Excel "databases". A dirty secret is that most (95+%?) of the data driven websites out there could probably use it (sqlite.org):-

        Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.

        The SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Dynamic content uses about 200 SQL statements per webpage. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time.

      3. jetjet

        Re: Nuts to them all. MongoDB is web scale.

        Yeah, you aparently never written multi user apps.

        1. Tim99 Silver badge

          Re: Nuts to them all. MongoDB is web scale.

          I've not used jdbc. With C, or even Python, it's a bit messy but doable for a few 10s of concurrent users on a LAN server. The good news is that it is extremely easy to port up to PostgreSQL if the application does grow.

          For most web applications the db talks to a single user, the web server. The post indicating hundreds of SQL statements per second on the SQLite site was made in 2015, I would imagine that it would have gone up since.

  6. Anonymous Coward
    Anonymous Coward

    With MySQL and MariaDB you get what you pay for. So you deploy what is needed by a product like Magento and then also deploy other systems that use other database products to take over the key roles as your needs grow.

    For most applications, the issue is not how the database handles transactions - it's how poorly those transactions have been coded within the application and that is before you consider how few applications even try to do correct double-entry accounting for financial work. Far too many systems are coded like

    Start transaction

    take funds from the payer's balance

    End transaction

    Start transaction

    place funds in the recipient's balance

    send out a email confirming payment to both parties

    let the log server know

    maybe take a tea break

    End transaction

    1. fg_swe Silver badge
      Thumb Up

      At least you have a log server, which can be used to replay all transactions !

      I have heard horror stories of small banks running on MS Access databases, so maybe MySQL is not the worst thing you can do.

      1. Anonymous Coward
        Anonymous Coward

        Not just small ones, unfortunately. 'Nuff said.

      2. Tim99 Silver badge
        Windows

        The run time version of Access as a front end to SQL Server might not be too bad. We made a few shrink-wrap apps each with ~50 concurrent CRUD users with tens of tables and a few millions of rows - The heavy lifting was done with transactions, stored procedures, and server-side views. BUT, the learning curve was steep and long - Once mastered it was a very quick and quite powerful toolkit to put useful Windows client-server systems into production.

      3. Anonymous Coward
        Anonymous Coward

        Natwest still uses FoxPro.

  7. Anonymous Coward
    Anonymous Coward

    Postgres is a database...

    MySQL/MariaDB is something that gets installed by something else that needs to store data. Both have their place, but Postgres is a competitor to commercial SQLServer and Oracle, while MariaDB is at most the backend to a website.

    Mind you MariaDB is still more modern, more fully featured, and better documented than Oracle DB. So Oracle fans (both of them?) shouldn't throw stones...

    1. Anonymous Coward
      Anonymous Coward

      Re: Postgres is a database...

      MariaDB is more modern and fully featured than MySQL. It's also more "modern" than Oracle if you look at the history of both. Saying that it's more fully featured than Oracle, though? You're either insane or a troll.

    2. beekir

      Re: Postgres is a database...

      MariaDB can't hold a candle to Oracle 11g on documentation, features or critically: performance.

      And I say that as someone who really dislikes Oracle DB.

    3. This post has been deleted by its author

    4. Anonymous Coward
      Anonymous Coward

      Re: Postgres is a database...

      > MySQL/MariaDB is something that gets installed by something else that needs to store data.

      I've had this argument on the SQLite front before too...

      I created a (very successful) bit of software than used SQlite as an underlying read-only datastore. If you made a change to the source of truth (the config file) the entire store was blown away and recreated.

      Along comes a dev - you should be using an ORM with that

      Fucking why? It's not a database, it's a data-store that uses a DB format for convenient.

  8. Kevin McMurtrie Silver badge

    Only 16 more years

    Las time I checked, MySQL can't run at all starting 2038. Set your clock forward and try launching it.

    1. fg_swe Silver badge
      Joke

      Re: Only 16 more years

      We all know the company will be sold to the Americans by 2025, why bother ?

      Make sure to be buzzword compliant with some AI and blockchains mixed in and diverse multigender. That will do.

  9. andy 103
    Meh

    For relatively simple use cases - of which there are so many - MySQL just works

    There’s a huge number of people who use MySQL who don’t care or know any better.

    Think of all those PHP applications (hello Wordpress, the most widely used web publishing system) or e-commerce platforms that also use it (Magento etc). Nobody using these applications cares about the difference. This also cascades to people building their own DB applications who think 1 million rows is “a lot”.

    Yeah there are some projects where the difference matters but for I’d say well over 50% of MySQL users there’d be no benefit of changing.

    1. Charlie Clark Silver badge

      Re: For relatively simple use cases - of which there are so many - MySQL just works

      There’s a huge number of people who use MySQL who don’t care or know any better.

      And it's their customers who suffer as a result. So much application code to work around MySQL's many defects…

  10. andy 103

    PHP is somewhat responsible for MySQL’s uptake

    I alluded to this in another comment but the “LAMP” stack - the last two being MySQL and PHP - has a lot to answer for.

    So many web applications use PHP and all the common ones (Wordpress, Magento etc) as well as frameworks (Laravel etc) either use or “strongly support” the use of MySQL as the database of choice.

    You only need look at the numbers of applications and sites running on LAMP stacks to understand how ubiquitous it really has become.

    The developers who cut their teeth on these simple CMS/e-commerce projects then know MySQL and so when building bespoke applications that’s their DB of choice. Unfortunately they don’t know it well enough to know the pros/cons of other choices. Ask a lot of LAMP stack developers about Postgres and you’ll get the reply “yeah I’ve heard of that”. And so it continues.

    1. mark l 2 Silver badge

      Re: PHP is somewhat responsible for MySQL’s uptake

      Yes unfortunately lots of web applications are so tightly tied into using MySQL / Maria that it is unlikely that they will ever support other databases without massive code rewrites..

      Take Wordpress there is a method to get the software to work with PostgreSQL but as lot of Wordpress add ons have very specific MySQL calls which then break the plugins if you use PostgreSQL database, it not worth doing unless you just need the core software with no add ons and really don't want to use MySQL.

    2. Mike Pellatt

      Re: PHP is somewhat responsible for MySQL’s uptake

      There, in one post, is why Django.

      Python

      PostgreSQL backend.

      1. andy 103

        Re: PHP is somewhat responsible for MySQL’s uptake

        @Mike Pellatt

        I'm talking about what is *already out there* though.

        When you look at figures - take Wordpress - there's something like 450 million installations in production. You're talking about a similar number of MySQL databases (even if you ignore staging/development environments used to create them). Whilst not an exact science the number is in the millions from that ONE application alone.

        When you factor in other PHP apps like Magento, or frameworks like Laravel/CakePHP you can see how that number will get into the billions.

        Unless somebody is going to replace all those *existing* sites/applications... clearly they aren't. It's already out there and that's due to MySQL being used as the default database on all of those applications.

    3. werdsmith Silver badge

      Re: PHP is somewhat responsible for MySQL’s uptake

      The car analogy again.

      MySQL/ Maria are the little granny shopping hatches, like a Focus or a Golf.

      They are perfectly adequate for most jobs, just don’t ask too much of them for load scale or speed. Of course you could use a fleet of little Golfs to scale. They won’t need a great deal of maintenance.

      Oracle is a 44 tonne multi axle truck, which in some circumstances can be tweaked to go fast. But you’re going to need a service team to keep it on the road.

      Postgres: SUV.

      SQL Server: Transit van

      Mongo and similar: these are your new dangled electric vehicles.

      1. Anonymous Coward
        Anonymous Coward

        Re: PHP is somewhat responsible for MySQL’s uptake

        > MySQL/ Maria are the little granny shopping hatches, like a Focus or a Golf.

        As ever, it depends on how much care you expend on them.

        Where I work currently, we use a fairly large and database sat in MariaDB, which drives a complex and highly configurable registration/management/tracking system.

        (To give some idea, we just cleaned out old data for a customer; this involved deleting approx. 6m items, each of which had data across approx. 300 tables. And even after this, some of their tables still have half a billion records in!)

        And we had a major usage spike at the start of lockdown, during which we were processing anywhere up to 200k items per hour. And since it's a complex system, each item generally involves half a dozen server requests, each of which can involve dozens if not hundreds of database calls.

        And while there was a bit of tweaking and a whole lot of active monitoring during this period, we came through unscathed.

        > Oracle is a 44 tonne multi axle truck, which in some circumstances can be tweaked to go fast. But you’re going to need a service team to keep it on the road.

        I used to work for a company which supported a major health-related system running on Oracle.

        However, this system had gotten to the point where installing Oracle patches had a bad tendency to break the system in various interesting ways.

        So they ended up uninstalling patches until they got to the point where things were considered stable enough, and then called a freeze on all further system changes.

        As you might be able to imagine, this made supporting this system - and getting anything useful from Oracle - extremely tricky.

        MySQL can scale. Oracle can be a nightmare. As ever, it's more down to how you build the data structures and system infrastructure than anything else.

    4. Dave559

      Re: PHP is somewhat responsible for MySQL’s uptake

      That is exactly the thing, I think: PHP and MySQL were in the right place, at exactly the right time, just at that point in time when the web was starting to move from hand-crafted static HTML towards interactive web applications, e-commerce sites, etc.

      They were both "good enough" back then, and 'word of mouth' counted as a strong recommendation, but it was a long time afterwards before people started to later realise that they weren't perhaps necessarily the "best" choices, but by that time a huge ecosystem had been built up around them (with too often the PHP apps being 'hardcoded' into using MySQL rather than having a database abstraction layer, unfortunately).

      1. ovation1357

        Re: PHP is somewhat responsible for MySQL’s uptake

        The problem with database abstraction layers is that they are forced into offering the lowest common functionally and inevitably end up having to allow raw queries or some other way tto permit the use of propriety commands...

        MySQL/Maria's 'GROUP_CONCAT' springs to mind here - immensely useful but specific to the DB.

        Oracle introduced something supposed to be an equivalent in 11i but I was not intuitive and it took me a while to get it to work for a simple report.

        I believe postgres doesn't even have an equivalent.

        ORMs and abstraction layers can seem like a good idea but I find myself fighting the abstraction to get what I want (and having to learn yet-another-ORM with its own syntax and idiosyncrasies) and then having to use some special exceptions which then tie it to one specific backend database again.

        Don't get me wrong, I don't hate ORMs and I do use them sometimes but so often I find myself thinking I could write a decent SQL query with much less effort, and/or finding that the ORM encourages writing poor/wasteful queries.

      2. Anonymous Coward
        Anonymous Coward

        Re: PHP is somewhat responsible for MySQL’s uptake

        In that sense python is the new php.

        In many aspects. Including the lack of architecture and long-term planning, suck, ...

  11. bigtreeman

    strength of conviction

    He didn't have the strength of conviction to leave when he first knew he was working on rubbish.

    Needed the paycheck, you dumb ass.

    A recent job with lithium batteries lasted three weeks

    because I couldn't put my name to shite held together with gaffer tape.

    1. Greybearded old scrote
      Joke

      Re: strength of conviction

      If I quit just because I was working on an utter sack of shite I'd never hold a job down.

      Icon? Well kinda sorta. Half anyway. Well, 3/4. Maybe 9/10...

  12. cdegroot

    I worked on some pretty large stuff with MySQL and when we joked that it was clear that it was written by a drunken Finnish student over the course of a weekend we were only half joking.

    Currently back with PostgreSQL after a couple of decades of not having it and it is totally boring. We use RDS so that makes it even more boring.

    “yawn” is good when it is managing your precious data :)

  13. flayman

    Careful...

    This guy's going to get a great big Oracle sueball hurled at him.

    1. Anonymous Coward
      Anonymous Coward

      Re: Careful...

      It may very all be true, but maybe not a very clever thing to post. I'd be questioning my decision if I'd just hired him. Don't know how these things work at Google but I wonder if HR have got wind of this.

      1. Anonymous Coward
        Anonymous Coward

        Re: Careful...

        "Don't know how these things work at Google"

        Well, he's bad-mouthing his previous project (and possibly employer), so he'll fit right in at Google.

        Don't be Evil. Be Very Evil.

      2. Anonymous Coward
        Anonymous Coward

        Re: Careful...

        At Google, they can even get away with badmouthing their own projects. Not every company demands total subservience from their employees.

  14. PM.

    It's Google !

    He is now @ Google .

    Google hates Oracle.

    Oracle hates Google.

    His new employers love his write up , I am sure !

    ( if not compelled him to write it .. )

    1. Anonymous Coward
      Anonymous Coward

      Re: It's Google !

      Does anyone know what Google uses as its database system(s) of choice, just out of curiosity?

      1. Anonymous Coward
        Anonymous Coward

        Re: It's Google !

        probably Lotus Approach.

      2. Anonymous Coward
        Anonymous Coward

        Re: It's Google !

        They brew their own stuff. Bigtable, Spanner, Google F1. Maybe a smidge of LevelDB.

  15. Rick Mo

    PostRe-Gress, more like it!

    You looking for a TRUE MONSTER RDBMS to leverage, to the starz??

    z/OS Db2 - aka, zDb2, Baby!

    That is the Rocket of all RDBMSs - billions of hits, per day - Just ask any Fortune 50, who run their BIZ on it!!

    ;-]

    Yeah, cloud is cute, too!

    TODAY, MAINFRAME zDb2 Rocks and/or Rolls!!

    1. tiggity Silver badge

      On mainframe, how about a shout for ADABAS too. Massively performant (non relational natively but can make it "act" relational very easily)

    2. W.S.Gosset Silver badge

      kdb+ too

      Yup.

      Also check out kdb+ with language q or k. Nothing comes near it for speed, plus deep maths/analytic capabilities arising from matrix-centric design and extraordinarily sweet (dis) aggregation esp.re time periods. All the big bank+trader players depend on it.

      Extraordinarily terse&powerful command set too :) It's a subset of APL -- check out wiki's APL example code for the Simplex algorithm for a long stunned pause :) Example k off wiki: full program to sort a list of words by their length is:

       x@>#:'x 

  16. bradh352

    High Availability

    The Galera cluster addon, either through codership directly, Percona XtraDB Cluster, or built into MariaDB I really think is the differentiating factor here. The fact you can run this reliably over low latency WAN environments in multi-master is nothing short of amazing. No need to try to choose a primary, and when that fails promote a secondary, then deal with rejoining/syncing the failed primary. It also allows for ACID compliance. When you look at solutions for PostgreSQL, a lot seem to rely on external scripts or proxies that are held together with duct tape and bubble gum ... and nothing supports ACID compliance unless it is an Active/Passive setup.

    Maybe PostgreSQL is amazing on the query language side, performance and reliability, and sure, a simple deployment is probably just as easy between MySQL and PostgreSQL, however deployment for high availability, that is way more complex (and inferior).

    Then there is the client API which is woefully inadequate. There are simple things that some other DBMS's support or aren't braindead about:

    * Multiple row binding to a prepared statement (bulk inserts! ... yeah yeah, you can do comma delimited insert values, but you then hit the max # of bound parameters really quick)

    * Client Side prepared statement handles (you have to manually declare a prepared statement and deallocate it when you no longer need it)

    * Defining row fetching size for large reports (until 9.2 PQsetSingleRowMode() didn't even exist, you had to wait for the full result set before processing)

    * Fetching column types from the server relies on you knowing the integer id of the datatype OID from the source code of the server (src/include/catalog/pg_type.h) as it isn't exposed in the client side api for some reason.

    * Fetching column lengths from the server, you have to know that things like VARCHAR they add an additional 4 bytes to the length returned, so its not a usable length but an internal storage size which is useless to an integrator.

    * There's probably more that I can't think of off the top of my head, but it was one of the more frustrating DB backend driver's I've written. (Granted, its not the only one with bugs, Microsoft has a long outstanding crash in their driver -- happens to be I hit the same as https://www.easysoft.com/support/kb/kb00808.html Issue #2)

    I haven't dived into the server-side code, but if the client-side is any indication, it gives me concerns.

    We've run with 100M rows no problem, but proper indexes are extremely important with MySQL, and if you didn't have the forethought up-front of creating the right indexes for you exact usecase (which of course can change over time), forget about creating new indexes, its basically impossible without a long outage window (Granted, I'm still on MySQL 5.7, maybe they've made this non-blocking in MariaDB).

    1. -v(o.o)v-

      Re: High Availability

      MySQL 8 with be Galera WSREP does writeset splitting so finally large schemas can be modified!

  17. Anonymous Coward
    Anonymous Coward

    To be fair…

    Back in the early 00s MySQL got popular in the context of LAMP as kind of a side effect of PHPs own popularity.

    The reasons were that, at the time, MySQL was being "sold" in newsgroups and nascent blog posts as a "more performant" (as in faster for some common use cases) alternative to PostgreSQL, which was also supposedly easier to get up and running with.

    But I don't think at any point anyone was under any impression that MySQL *was* the better database. It was just the more accessible low hanging fruit. As I recall, at the time even MySQL's documentation was quite candid about it.

  18. tiggity Silver badge

    familiarity & easy integration

    Using the familiar is a big thing, as is how a DB plays nicely (or not) with the language you use..

    If I'm cobbling together some little "mickey mouse" personal project on windows using an MS language that needs a DB I use SQL Server. Massive overkill, but its a DB I am massively familiar with so no hidden gotchas & integrates well with the MS languages.

    .. though sometimes you do something off piste just for odd reasons, e.g. for one club I am involved in, where initially only a small amount of data needed storing, infrequent updates I did it using XML files as the backing store (as a nice learning exercise in XML querying and manipulation, and because structured the data so I could run XSL transforms on the data (again, good learning process) to generate HTML markup fragments and update the website static pages very nicely).

  19. Yet Another Anonymous coward Silver badge

    Why does Oracle keep MySQL ?

    Is MySQL just Oracle's gateway drug ? When your application becomes big enough the Oracle salesman calls?

    Or is it to do the "MS-Office effect" and stop anyone else getting market share? It's an alternative to pirating Oracle for people who can't afford Oracle but it means nobody else can charge money for any low power solution ?

    I'm assuming that if MySQL didn't make $$$$ for Larry's yacht fund it would be shut down. Not a database person so no experience.

  20. Ken G Silver badge
    Facepalm

    Papal religious preferences clear

    Portaloos just not up to the job, says Bear

  21. a_yank_lurker

    Right Tool for Task at Hand

    To be blunt, Gunderson is an idiot. Different db engines and types are tools. An intelligent data manager is familiar with various tools and selects the best one for the application. If a relational db is best, there are several to choose from based on the scale and complexity of the data. Other types have there niches were they shine. To say one db is garbage like Gunderson is saying shows he does not understand there are many applications were MySQL and clones/derivatives are quite suitable but Postgres would be serious overkill. Now there are applications were MySQL is not suitable and thus something else should be used such as Postgres. Is MySQL used where it should not be? Certainly.

    1. Charlie Clark Silver badge

      Re: Right Tool for Task at Hand

      there are many applications were MySQL and clones/derivatives are quite suitable but Postgres would be serious overkill.

      That it simply not true. In the past, you might have gone with MySQL for the apparently better performance (at the expense of integrity). But this was always possible in Postgres by simply disabling integrity. But that is mismatch and non overkill. Overtime, that lack of data integrity and, oh, things like table locking would come back to haunt you again and again and again.

  22. Anonymous Coward
    Anonymous Coward

    "Well, it's one louder, isn't it?"

  23. JulieM Silver badge

    A Bag of Grapefruits

    They don't like MySQL because of the licence.

    MySQL is licenced under the GPL, which says explicitly, "Not sharing is stealing". Every contributor to a GPL project can be sure nobody is going to take their hard work that they intended to be for everybody, alter it very slightly and turn it into a proprietary project that denies users the freedom to enjoy, study, share and adapt it.

    Google love the Apache licence, which only says "Sharing is not stealing". You can release an entire application in binary form only -- not a single byte of Source Code anywhere -- under the Apache licence, and proudly trumpet it as being "Open Source". The Apache licence gives you permission in theory to study, share and adapt the Source Code; but crucially, it does not require the licensor to make this possible in practice.

    It is this loophole in the Apache and BSD licences that makes them so ripe for abuse by bad actors such as Google.

  24. Andy Denton

    Firebird....

    ....has been my DB of choice for the past 15 years or so. It just works. No DBA required either. I've got clients that have been hammering it daily for over 10 years and it's never missed a beat for them. Shame it never gets the love/exposure the mySQL/Postgres do.

    1. W.S.Gosset Silver badge

      Re: Firebird....

      I admit I'd never heard of it. Looks good from a glance at wiki. Question though: do you know if it can do genuine serialisability? Or does it use a nearly-there-but-not-quite approximation like postgresql? (I.e., can it block intra-transaction inserts into your predicate by another user? Postgresql doesn't/can't.)

  25. J27

    I'd still rather use MySQL than Oracle Database, talk about an overpriced dumpster fire.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like