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 …
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.
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.
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.
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?
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.
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?
"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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
