Slashdot Mirror
Oracle Fiddles With Major Database Release Cycle Numbers (theregister.co.uk)
An anonymous reader shares a report: Big Red has changed its database release cycle, scrapping names that see decimal points and numbers added on for an indeterminate amount of time, instead plumping for annual releases numbered by the year. So what would have been Oracle Database 12.2.0.2 will now be Oracle Database 18; 12.2.0.3 will come out a year later, and be Oracle Database 19. The approach puts Oracle only about 20 years behind Microsoft in adopting a year-based naming convention (Microsoft still uses years to number Windows Server, even though it stopped for desktop versions when it released XP). [...] Well, Big Red will surely be using the revamp as a way to boost sales of database licences -- a crucial part of its business -- which have been in decline for two years running. In fiscal 2016, Oracle reported a 12 per cent drop in annual sales of new software licences, and its most recent results for fiscal 2017 revealed a further 5 per cent drop. And, for all that Oracle has shouted about its cloudy success of late, it isn't yet a major money-maker for the biz. New software license sales make up a quarter of overall revenue, while support for that software makes up a further 45 per cent. In part, the new numbering will be a handy marketing ploy. Rather than playing with the decimal points, a release with a new whole number could be an attempt to give the impression of agility in the face of younger, fresher competitors. Meanwhile, fewer patches and releases on each system also allows Oracle to know more quickly, and more accurately, what security features each customer has. The annual numbering system is also a very simple way of telling you your system is old.
I was an Oracle user for 25 years, took my first course on Oracle 6 in 1991. That was the introduction of it into my employer (City of Calgary) which was locked in IBM mainframery at the time; they had to accept Oracle as needed for GIS mapping, the ESRI and other GIS products all practically demanded Oracle.
Now, I was not up at the sysadmin end, where Oracle's tools for moving whole databases about, and spreading them across disks and servers and all that, are greatly appreciated. But just as a user, all the needs I had for a GIS database had been replicated in Free Software by the time I retired.
I think Postgres stacks up fairly well against Oracle, even for the sysadmins fussing over partitions and multiple servers, these days; but for my needs, now considered humble, a mere 10GB database of every pipe, every house, every lot and street, every bit of water infrastructure in a large city and all the work-orders done on those pipes in 10 years - was handled by PostGIS (Postgres with a GIS plug-in) with ease. On a laptop. I started doing real work on my PostGIS copy (and no, transfer from Oracle to Postgres was not remotely difficult) because I had more control over it, was the DBA. Convenient sometimes.
I guess some Oracle admins will always have a situation where they can say "the free software alternatives just don't let me manage my petabytes easily for 365x24 service", fair enough.
But so many work needs can be handled well by a reliable database product that can manage a mere few hundred gigabytes quickly and well, that I think if everybody who *could* switch to Postgres *did* switch to Postgres, Oracle would be trying to fund itself on a small fraction of their current customer base, though they would all be huge customers.
I wouldn't have written that in 2012 when I first looked at Postgres, but their developments since 8.5 have been especially impressive. I recall a debate in their committees a few years back where they worried not enough developers were handling the routine bug-fixes and minor upgrades with each version: too many people were excitedly putting in major new features like 'big database support' and UPSERT (9.5), "parallel query and synchronous replication" (9.6) and so on, to take care of basics. They've had a very impressive five years. As to the predictions for Postgres 10, I can't even understand them: http://rhaas.blogspot.ca/2017/... ... but they are apparently awesome from the fan reviews.
I tried to get IT at work to have a look at Postgres, but it was a non-starter: our PeopleSoft application is married to Oracle and there's no way they'd have two DB products. Indeed, Oracle may be safe for decades yet unless somebody like EnterpriseDB comes up with a really popular Oracle-to-PG migration for both SAP and PeopleSoft. Those things could not be removed from most large corporations with a nuclear-powered crowbar, so they're Oracle's best lock-in partners right now.