back to article Oracle nemesis MariaDB tries to lure enterprise folk with TX 3.0

Open-source database biz MariaDB has upped the ante in its war against Oracle, promising enterprise customers better compatibility with – and easier migration from – Big Red. The Finnish firm's latest offering, MariaDB TX 3.0, released for GA today, extends the number of use cases to include temporal processing and advanced …

  1. LDS Silver badge
    Devil

    "From the top down, they wanted to embrace open source"

    From the top down, they don't want to pay the Oracle prices....

    "migrated over 2,000 lines of PL/SQL, "

    2,000 lines? What was that, the annual picnic booking application?

    1. shane.k.j

      Re: "From the top down, they wanted to embrace open source"

      Typo. It's 200,000+

  2. Stuart 22
    Happy

    dBase?

    Great to see dBase hanging in there at a stable 37 in the DB-Engine rankings. I guess MariaDB hasn't figured a migration path yet. Is being able to read legacy data from floppies getting a bit hard these days ... ???

    RIP Ashton-Tate.

    1. LDS Silver badge
      Facepalm

      Re: dBase?

      Oh well, Access is still in the top ten....

  3. ValleyBoy

    "Red Rover Migration Team"

    I like that, that's funny

  4. Charlie Clark Silver badge

    Postgresql is the real winner

    Postgres started getting wide adoption after Sun bought MySQL and take up accelerated once Oracle got involved. Companies like Enterprise DB have long-targeted Oracle customers and have invested in developing the features and tools they need to migrate with as little effort as possible. This is borne out in the DB Engines rankings which show much stronger MoM and YoY growth for Postgres than for MariaDB. In summary, Postgres is the open source database of choice.

    1. Lars Silver badge
      Coat

      Re: Postgresql is the real winner

      Postgres is one open source database of many choices.

  5. TVU

    Oracle nemesis MariaDB tries to lure enterprise folk with TX 3.0

    I don't doubt that this move will increase MariaDB's use and popularity although there's still a long way to go before it catches up with other open source databases.

    As for Oracle, they are still sailing on the ship of complacency and they seem late to the party when it comes to trends like cloud database storage and big data that could affect sales of their RDBMS database.

  6. Anonymous Coward
    Anonymous Coward

    Years to port 2000 lines?

    I call shenanigans.

  7. TheVogon

    "However, it has risen up the DB-Engines charts in recent years, now ranked 14th overall"

    So below Microsoft Access.

    "Oracle Nemesis MariaDB"

    Oracle's nemesis is really Microsoft SQL Server - which with the recent AAG features can replace even Oracle RAC Server at a much lower TCO.

  8. Bryan Hall

    For Oracle Spatial - just use PostGIS

    We are migrating away from Oracle. On the spatial databases that is to PostGIS (PostgreSQL). While not a direct conversion (EDB is no help there), it really isn't that hard.

    For new non-spatial work, if it doesn't need to be elastic (most things) - PostgreSQL. Otherwise we are looking at NuoDB for things like microservices.

  9. W.S.Gosset Silver badge

    SQL-92 Compatibility?

    Anyone know if MariaDB is SQL-92 compatible, specifically: offering serialisable transactions? Or for that matter, PostGreSQL?

    Reason I ask: neither Oracle nor Sybase*cough*SQLServer can do serialisable transactions. They can't Isolate users.

    Well, they sort of can... but then the locking granularity is Table. ie, if you want serializable transactions, each one locks every table it touches for the duration. ie, every other user is locked out of all the tables. So, not real-world.

    Another way of putting the question: can MariaDB & PostGreSQL do predicate locking?

    1. Anonymous Coward
      Anonymous Coward

      Re: SQL-92 Compatibility?

      I think you may have to re-read Oracle documentation about SERIALIZABLE isolation level - it doesn't escalate locks to table. You can't modifiy a row unless Oracle can ensure it wasn't changed since the transaction begin. Oracle uses the rollback segments to read older data, and a recent history of transaction for a data block (see INITRANS).

      Sybase/SQL Server - which for a while shared the same engine, were known to escalate locks quickly. That's why in the past (i mean over ten years ago) I always preferred Oracle to SQL Server, the latter could deadlock to easily if you needed proper transactions.

      Just remeber SERIALIZABLE can't be used "just because" - long running transaction which modify a lot of data may not play well in that mode. AFAIK it changed now.

      1. W.S.Gosset Silver badge

        Re: SQL-92 Compatibility?

        Hi

        I can confirm that Oracle's documentation states (despite enormous obfuscation) that in fact it behaves exactly as I said. Took me quite a while to establish that -- they are clearly corporately defensive about it. To be clear: it can not do predicate locking so can not offer full transaction Isolation, other than via table locks, which it auto-escalates to.

        What you describe is actually Oracle's proposal back to the Standards committee for a brand new definition of a brand new Isolation Level. Because they couldn't do the real thing. And it is their default "max" unless you specify The Real Deal.

        The Standards guys rejected the proposal btw.

        Does anyone know the situation with MariaDB & PostgreSQL?

  10. disgruntled yank Silver badge

    "and a stored procedure language compliant with Oracle PL/SQL, with the idea being to demonstrate that customers can reuse existing code and skills when migrating applications or deploying new ones."

    Compliant?

    EnterpriseDB supposedly provides full PL/SQL and quite a few of the Oracle standard packages.

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

Biting the hand that feeds IT © 1998–2021