Oracle's letter to Russian IT companies
postgresql.orgOracle is beginning to find they are in trouble. Here's a small example: I'm hearing from a fairly reliable source that quite a few large Australian banks are replacing Oracle (my source didn't say with what). They are citing the enormous cost of the licenses, along with difficulty getting adequate support without paying a fortune. My contact himself is in upper management of a large corporation and Oracle screwed him on licensing, forcing him to pay a huge amount of money from his budget that he badly needed to spend on other projects. This delayed these projects by about 3 months, and put a bit of pressure on the area of the business he oversaw. He's also investigating the best way of quietly getting rid of Oracle as fast as possible. That will take some time, but he's at the point of rejecting any new solutions that require Oracle products.
I'm not at all surprised. Medium sized businesses used to use Oracle due to perceived reliability and features, however there have been a number of things that are making them reconsider:
* A number have been shaken down by Oracle sales reps who threaten a license review and potentially stiff penalties and litigation if they find anything at all out of order - unless they purchase software they don't need.
* difficulty in getting support - Oracle are notorious for not responding in a timely fashion to tickets, and a willingness by the CSO to completely ignore serious security flaws.
I experienced this myself four years ago when my boss put me in charge of a clear Unicode bug in their OLEDB driver - the bug had been open for 2 years and by the time I left a year later Oracle had almost wilfully ignored everything we wrote, even ignoring a program we built in .NET that showed the problem. Throughout the ticket we dealt with something like 4 support people, each of whom didn't understand Unicode and who needed a basic backgrounder on how UTF8 works.
* license costs are ridiculous, and frankly not worth it.
* it can often be hard to find people who can troubleshoot performance issues. Even highly skilled people face a black box when they work on improving query performance as the CBO is largely a black box that can change from version to version. Without a clear explanation of how the CBO actually makes decisions it's often a bit of a crapshoot when tuning queries.
* Oracle DBAs are very expensive, compared to how much you can pay an equivalent skilled DBA who knows Postgres or even SQL Server.
* there are few features most medium sized businesses need that can't be done in Postgres.
I work for a major bank and Oracle is on its way out here. Trouble is, when it's running your general ledger and is tightly coupled to your core banking operations, migration to another platform can be a decade-long process.
Yeah, but on the bright side once your excised Oracle and replaced it with something better Oracle won't be coming back any time soon :-)
Unfortunately I didn't say we're moving to something better cough SAP :(
My sympathies.
> * A number have been shaken down by Oracle sales reps who threaten a license review and potentially stiff penalties and litigation if they find anything at all out of order - unless they purchase software they don't need.
Woah. So essentially Oracle's "sales" reps behave like the mob. How have they gotten away with this for so long?
They also take a lot of executives to strip clubs.
Well, we know of at least one occasion:
http://www.sfgate.com/bayarea/matier-ross/article/Strip-club...
Do you know of any others?
> Oracle DBAs are very expensive, compared to how much you can pay an equivalent skilled DBA who knows Postgres or even SQL Server.
Note that sensible Oracle consultancies are openly offering similar support for Postgres. This can occasionally be useful ... assuming they can realistically supply that level of support e.g. when a PG fills its disk or various other disasters happen. (We've been testing our PG clusters at work with various test disasters and making sure we can recover from any of them with as little faff as possible.)
> it can often be hard to find people who can troubleshoot performance issues. Even highly skilled people face a black box when they work on improving query performance as the CBO is largely a black box that can change from version to version. Without a clear explanation of how the CBO actually makes decisions it's often a bit of a crapshoot when tuning queries.
This has not been my experience.
What part of parent has not been your experience ?
I have experience parent's woes and more. That includes having Oracle staff in house doing in-person knowledge transfer. Experience says that Oracle will not provide a qualified person if we call for one as well. Sourcing from their own consultant pool is also a black box crap-shoot.
We also involved Dell and their support team to provide feedback and second opinion on Oracle CBO, query optimization and overall needed knowledge to use their Toad for Oracle performance tools. They literally stopped short of saying: yeah, you need people smarter than us for that.
I still think Oracle is a great product, but it's only fit for large organizations with bottomless budgets. I think we spent something north of $100K on Oracle's E-learning and that was probably the cheapest item on the list.
> What part of parent has not been your experience ?
We have several people in house (I know of 6) who can troubleshoot performance issues. For them the CBO is not a black box and they can explain what is happening and why.
I know of a local consulting company that has several very good people that you can "order". Said consulting company also offers very good CBO courses/workshops.
Really? I have a book on CBO performance troubleshooting from the foremost expert and even he says that he can't fully understand why the CBO does the things it does.
I doubt your in house experts fully understand the Oracle CBO. They may claim they do, but unless they have access to material that isn't public they can't possibly be able to diagnose the CBO fully.
You realise there are over a thousand hidden database parameters, right?
> Really? I have a book on CBO performance troubleshooting from the foremost expert and even he says that he can't fully understand why the CBO does the things it does.
> I doubt your in house experts fully understand the Oracle CBO. They may claim they do, but unless they have access to material that isn't public they can't possibly be able to diagnose the CBO fully.
Maybe. Let me put it this way, so far they could explain all CBO decisions where we had performance issues.
Why do companies choose Oracle nowadays? I mean valid technical reasons, not being clueless or stuck in the abusive relationship of vendor lock-in.
My experience has shown me that Companies will buy/use technologies based on two pillars, Trust and Value. The pillar of trust takes an enormous amount of time to establish and can be decimated very quickly. Trust is about 95% of any buying relationship. Companies will even buy products they don't understand the value of because they trust the vendor it comes from.
PostgreSQL doesn't have the network of value added resellers and internal sales reps that Oracle has amassed. These are people that engineers dismiss but management often see them as a support tier for their customers of a product. That tier builds trust.
If you try to introduce your product/service to an enterprise B2B market with an established market leader and intend to sell or distribute entirely off of value alone you will lose nearly every time. In smaller companies that can't dream of licensing Oracle the risk is worth the reward, it's not like they have a choice and they then grow an in house knowledge to be that support tier if they scale.
Consider that I f something breaks at a big enterprise it's likely to cost millions of dollars in lost payroll while it gets fixed. Big companies would rather mitigate the risk and buy a supported and proven product. They trust it.
> Consider that if something breaks at a big enterprise it's likely to cost millions of dollars in lost payroll while it gets fixed. Big companies would rather mitigate the risk and buy a supported and proven product. They trust it.
One facet to trust is your personal career: as the manager who signs off on this, you can trust that if anything goes wrong Oracle will aggressively defend your decision — people, including high-level managers, will show up on site to defend the decision and promise to fix whatever went wrong, consultant reports by the pound, etc. If you go with Postgres, you're going to have to do more of that yourself and if the amounts were at all significant, you can be very confident that Oracle will have people telling your C-level management that this never would have happened if you'd gone with them. Even going with Microsoft can be seen as “risky” for that reason.
Im curious how many who claim the "No one ever got fired for buying IBM" thought process about paying for Oracle for their support or so they can blame someone else for being lazy and incompetent have ever USED oracle support. Waiting a week or longer for a patch with no work around is not uncommon, and not exactly something I would pay for.
Yup. I have never had much luck with support except sort of some big known problems or something where you can afford a lot of time. Most of the time you end up figuring out the problem or a workaround long before it gets pushed to some real engineer. And even when you diagnose the problem partially they will simply ignore you and ask rota questions and 5 days later give you the solution you have come up with in case they come up with one.
I think those happen at completely different levels and there are a lot of places where the communications process either doesn't work at all or has significant translation issues. Here's what it looked like at one job:
My level:
1. Internet Explorer 8 is released. Our users start to get the automatic update and our very expensive Oracle reporting app breaks.
2. I contact Oracle's support and get a very snotty customer “service” person:
“I noticed a bug in your JavaScript code which now triggers an exception on IE8.”[1]
“We don't beta-test Microsoft's software for them. We'll start testing IE8 when it ships.”
“That was last week. How's the testing going?”
pause
“We'll get back to you”
“Please do. I deployed a patch but am worried there are more subtle problems.”
3. <days pass with no contact>
4. “Hi, this <senior support manager>. Can you give us a copy of the patch you mentioned so we can distribute it to other customers who are dead in the water?”
5. <time passes>
6. “You'll need to upgrade to $NEXT_MAJOR_VERSION, which was just released and is a paid upgrade”
The executive level where the decision to buy was actually made:
“Hey, heard you guys had a problem or two but the support group worked it out”
“Yeah, the usual. Are we still on for our normal tee time?”
The problem was that the executives didn't have any experience somewhere dramatically better functioning and both the outside sales team and their staff who had invested much of their professional development in that stack had an incentive to downplay problems and come up with reasons why any particular outside comparison wasn't valid. No large organization works exactly the same as its peers and so you can always come up with some argument for why they can do something but it won't work for you. The only thing which seems to disrupt that is either a failure too big to be excused or the emergence of an alternative which is either dramatically cheaper or does something new such as support mobile/BYOD or a cloud service which removes the need to have the staffing and equipment in-house for a major app.
1. This was actually a neat class of failure: the IE7-emulation mode solved most of the display problems but it was still using the IE8 JavaScript engine, which raised an exception when a library attempted to set zIndex to a completely invalid value like null, unlike the real IE7 engine which simply ignored it. I pity whoever at Microsoft maintained the test suites for those enterprise compatibility modes…
Honestly (having been through plenty of meetings where this type of stuff happens) it's because Oracle has someone out there spreading the word to The decision makers. The Oracle sales team isn't converting developers, they're in the ear of the person who signs the check.
Nobody is out there on the Postgres side doing the same, so that decision maker doesn't even know who they are. Then when someone suggests pgsql for something, the first question is, "Where do we get support?" Everyone then looks around the room and starts searching the web for support.
There is no question if and who will support you with Oracle (which is why I will never choose them).
But should not the decision makers be smart enough to see through this? If they sign contracts, they should do a proper research first.
Just believing a well-known company which presents their product as "the solution to all your problems" does not seem very clever to me.
I'd say it's less 'smart' and more due diligence. I agree that you should know at least SOME alternative options to things. We're seeing more tech Managers/Directors/VPs/whatever that used to be engineers or architects and I think we'll have more people that fairly recently (or still do) had their hands dirty in project work. The new wave of leaders are much more technical than the previous wave of leaders. But the problem still remains that once you've been away from the daily low level work, things move on without you. There will always be some disconnect. I think the new wave of leadership will better know that and hopefully respond a little better by having people propose alternatives to them, personally finding alternatives, etc.
I know that when I don't have the knowledge in a particular area, say payment processing, and I can only think of a vendor or two off the top of my head, it becomes someone's assignment to bring me the pros and cons of the major vendors and maybe a couple of the upstarts- including getting on the phone with them if necessary. The ultimate decision will be a combination of that person's recommendation vs. any business problems that may prevent a relationship (say some certification or SLA forced on us by the client).
There is also the psychology aspect of a well known name. They must be a well known giant because they are good, provide the best, or provide something the others can't- right? Now, WE know that mostly Oracle doesn't do these things. There are a few cases where they have kind of engineered a way to be the only one who does the thing (then got someone to make it a requirement in their project). We know they're generally abusive, and awful to work with. A not very technical decision maker just knows Oracle is a big name. Just like SAP. I'm not saying it's an excuse, it just is.
You are right, but there's a way around the argument that allows them to still make a bad decision. It's called management by committee. They don't need to provide a good fit-gap analysis, sound points for the plan or quantify why it's better. You will simply hear that a group of smart people have concluded that it's a "good plan" and that they consulted with Oracle and their own experts who are also absolved of any responsibility since lack-of accountability is built-in to their contract.
It will cost a lot in time and dollars to actually get what you want and you will not want to litigate Oracle.
A common reason seems to be that the person in charge of procurement puts importance some operational aspect that Oracle has that other RDBMSs do not have. For example, some specific availability scenario that Oracle RAC solves, some security feature like row level security (which Postgres does have now) or some disaster recovery thing in RMAN. Most procurement processes only consider price once all criteria have been met so a common "attack vector" for an Oracle salesman is to get some criterion added that only Oracle can provide :).
The other common reason is if you'll be deploying some existing application on top of your RDBMS and it either only supports Oracle (ie: it uses Oracle's proprietary language somehow or simply not ported to Postgres) or you already have lots of Oracle DBAs. Most big organisations are very brownfield so the technology choice is path dependent.
I think you're right, particularly about the apps – if you don't work at a large shop it's easy to forget how many businesses run the various financial apps which Oracle sells, and such apps tend to be used by senior management so e.g. the CFO is voting against changes unless there's a really good justification. Once you've got it in house, the argument will be that you don't want to have to hire experts for more than one database, which is how some people end up running a normal web app on Oracle because it's the only supported HA/backup/etc. option offered by the central IT group.
At one previous employer, we had to deal with several hours of downtime daily because they kept not getting the $$$$ budget needed for Oracle's online backup product and so it went down for how ever long it took to write data out to a poorly configured tape backup. Trying to use MySQL or Postgres happened by necessity but was heavily FUDed over what might happen and all of the (internal) users had just been trained that the systems weren't available before 7:30 AM.
They buy application suites like peoplesoft, Oracle Finacials, Identity Suite, seibel, etc and end up getting an ELA for the database.
Once they get the shoulder in the door, they push to expand the database horizontally in the organization.
Microsoft has a similar strategy with CRM and SQL Server. SQL Server drives their corporate success.
Postgres vs. Oracle, etc is a pointless argument because it's answering the wrong question.
The comparison with SQL Server is not very sound. SQL Server is MUCH cheaper. I would venture to say it is more performent and is on-par with features (certainly will be after the next realease). Moreover. SQL Server is not brute forced in the way you say Oracle is, especially with CRM. Maybe something like that happens with the ERP products, but much more mildly.
The most important difference is that SQL Server has everything that Oracle has to offer at a much, much cheaper price.
I agree that comparison with postgres and mysql are pointless. They offer a tiny fraction of what enteprise products have. If you need it, you will know.
SQL Server has everything that Oracle has to offer
One thing that comes to mind is Linux (or Solaris, HP-UX, or other nixes) support. SQL Server is essentially Windows-only.
Assuming this comes to fruition[1], SQL Server is going Linux middle of next year. Crazy times in Microsoft land
[1] https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-s...
Yes, that's why I said this statement will be true for the upcomming release. I don't think this particular feature is that important anyway. Being Windows only has allowed SQL Server to e much more performent in many cases. Cost is not a factor.
The main advantage Oracle has over SQL Server in my opinion is that Oracle has tablespaces and multi-version concurrency control baked in, whereas SQL Server has ONE TempDB and snapshot isolation relying on that one TempDB.
On the nose. SQL Server is a great product, but their MVCC is basically hacked in. They're also lacking in the features Oracle has around their Undo tablespace, and auditing.
As a PostgreSQL user I dread the idea of running a database without MVCC, even MySQL and SQLite have decent MVCC support.
Then you really don't want to read about escalation locking...but if you want to be horrified visit the following:
https://technet.microsoft.com/en-us/library/ms184286(v=sql.1...
Postgres MVCC is anything but decent. It will take over control of the main heap. Good luck tackling that.
What exactly does that mean? MVCC is definitely different in Oracle and Postgres, but that doesn't mean it "takes over the heap" it just means it stores a new version of the row in the same heap. Later on an auto-vacuum process clears out the old heap page, or sometimes on demand when a select, update or delete accesses the row.
Oracle stores the old version of the row in a rollback segment.
According to the following article, "only changed values are written to undo whereas PostgreSQL/SQL Server creates a complete new tuple for modified row. This avoids bloat in the main heap segment." [1]
1. http://www.enterprisedb.com/postgres-plus-edb-blog/amit-kapi...
The very next sentence:
Both Oracle and SQL Server has some way to restrict the growth of version information whereas PostgreSQL/PPAS doesn't have any way.
True, this can be an issue. But the auto-vacuum and auto-cleanups should resolve this issue. Have you experienced this as an issue? Genuinely curious.
(Don't speak to me about SQL Server. Of all the brain dead ideas, implementing storage in the TempDB for snapshot isolation!)
It is cheaper than Oracle in many scenarios. Either way, Microsoft's profits and Wall St. satisfaction is driven by SQL Server sales.
One overlooked aspect is the career prospects for someone in IT working with an Oracle system. It is a network effect where career prospects dictate the system chosen which in turn makes the system more prevalent. Soon they are known as someone who has overseen an installation/maintenance of an Oracle system and can look forward to a stable career. In contrast someone installing a postgres system will not have the same opportunities.
It is a similar dynamic with SAP another much detested system by everyone who is not in IT or works as a consultant. It is amazing to me, pretty much everyone who actually works in an SAP (or Oracle) system detests it but cannot get IT to provide an alternative.
If your operations are tied in some way to government, it might be required that software you are using have legally recognizable developer or owner, officially certified by competent government structures (e.g. in terms of being secure) and/or has someone who is contractually obliged to help you resolve any issues you might face while using it.
I would assume Oracle has a very strong presences in Russia in those terms. Unlike Postgres until Postgres Pro.
More details (in Russian): http://obartunov.livejournal.com/181484.html
IMO the principal advantage commercial RDBMS platforms have over the open source ones is query parallism [0], which can be a big advantage for certain query workloads.
Postgres and others are working on solutions for this, and I find more shops look for alternative solutions instead of paying for Oracle licenses.
[0] https://wiki.postgresql.org/wiki/Parallel_Query_Execution
One reason is that you want to run applications (finance, ERP, CRM) that are owned by Oracle and therefore require the Oracle database engine.
No one has ever been fired for recommending Oracle. And if you can't code, the horror-show that is Oracle Apex seems like a good idea.
Have you used apex 5. I've seen apex applications created by good developers (who can code with sql, pl/sql and javascript) which have been nicer, more reliable and definitely more performant than some java or.Net Web apps.
> Why do companies choose Oracle nowadays?
No one was ever fired for choosing Oracle.
Let me say again how our workplace conversion from Oracle to Postgres has made EVERYTHING SO MUCH BETTER. Not just from never having to talk to Oracle ever again - but the fact that we can give every app its own PG clustered pair without ever having to think the word "license". Nothing has to play nice with anything else.
(We also have some MySQL - from old in-house apps and from third-party things like Drupal, Magento, WordPress and MediaWiki - and some MongoDB, which we're pushing to get converted to Postgres because it does key-value comparably fast and means one less dependency, though that's nothing like as urgent as getting off Oracle was.)
Yeah, until MySQL gets a corrupted LSN that points into the future and you have to dump the table then reimport it... :P
AAAAAAAAAAAAAAAA
Chris is referring to this: http://rationalwiki.blogspot.co.uk/2016/03/mysql-database-pr... which I eventually resolved by carefully hand-exporting the corrupt table to CSV and reimporting it. I think we lost one revision from 2008. I HATE MYSQL SO MUCH.
(unfortunately, MediaWiki is one of those things where MySQL or preferably MariaDB is the only realistic option - other DBs are hypothetically supported, but in practice not well enough unless you want to do the heavy lifting yourself.)
Postgresql's greatest advantage - no headache from dealing with BS from Oracle or MS.
+1
We have been building/rebuilding our applications on top of PostgreSQL but there are still a lot of departments that buy the "Oracle is better / We need paid support" propaganda. Props to Russia for their forward thinking views.
You can get paid support with Postgres : http://www.enterprisedb.com/products-services-training/subsc...
We've been using 2ndQuadrant for a few years and love working with them: http://2ndquadrant.com/en/support/support-postgresql/
They are mentioned in original PDF on page 7 http://www.postgresql.org/message-id/attachment/43080/Postgr.... Mentioned as a company and a product, that has lots of add ons on top of PostgreSQL for reliability, distributed computing and operability.
Pay hundreds of thousands in support contracts, get peanuts (and/or worse advice than the documentation).
Using Oracle product in a non-Oracle VM?
Now you get the privilege to pay licensing for all the cores in your environment where you can migrate the VM to.
With such a policy, what could possibly go wrong?
Free software saves money because you don't pay per core/processor/user/whatever. With proprietary software, you have to agree to auditing by the vendor (or their representative) and they decide whether you're in compliance. Why anyone would willingly agree to such agreements is beyond me.
Hmm, this part:
It's poorly written in terms of Russian grammar,
suggests that rather than being a "rogue" effort by an overseas affiliate (which Oracle will no doubt try to spin it as, once this turd floats to the to the top of the English-speaking business press, as it hopefully will), it's more likely that someone directly with Oracle provided a few "talking points" in English, and these were hastily translated into Russian by someone local (i.e. using GT or some other tool, and carelessly edited).
Would be very interesting to have an open document listing alternatives from the PostgreSQL universe to every point in that document (a gitbook maybe?). A few minutes ago I was thinking that "database firewall" could be a problem, but then I found [0] immediately.
I love that chart on the second to last page. The axis are labeled "Completeness of vision" and "Ability to execute".
Oracle:
Vision: Screw customers over and get their money. Execution: Very probable, customers don't run fast enough.It's kind of funny that they included that when Microsoft is beating them on both axes (and with a far lower TCO).
I have this feeling that Microsoft is going to be announcing some really big things in the data management area in the next 12 months.
This is Gartner's famous "Magic Quadrant".
You can download the whole report from Microsoft (not surprising, since it came out top):
https://info.microsoft.com/CO-SQL-CNTNT-FY16-09Sep-14-MQOper...
I've posted a big version of the Magic Quadrant here: http://imgur.com/3qFwPd6
Which is largely used for propaganda and often doesn't exactly mean very much.
The Magic Quadrant is just the eye-catching bit of what is generally a fairly substantial (15,000-25,000 word) report.
I'm assuming Oracle is in the lower left?
Gartner identifies Micrsoft and Oracle as the leaders on the top right.
Mongo, EnterpriseDB and Redisnare in the upper right as well.
While they did add EnterpriseDB, they left out Postgresql.
It also seems like the chart is stuffed with a ton of databases you wouldn't even consider, just to make it look like they are more ahead than is really the case. It's not that the databases in the lower-left aren't any good, they just fulfill very different roles.
I would be curious to see the evolution of the revenue of Oracle in Russia for 2016 Q1, including its Y2Y growth and the direct effects of the introduction of this law. The sole existence of this letter is proving that revenue took a serious hit.
This semester I am taking a DBMS course and the instructor works at one of NASA's NSSDCA center in South Dakota.
He mentioned in that class that, this NSSDCA center is in the process of moving away from Oracle to PostgreSQL. The transfer process is going on for over 2 years.
Even the book we are following changed their focus from Oracle to MySQL from recent edition.
I'd be asking the lecturer to change yo a different textbook...
What's wrong with the current book?
This is what we are reading : Database Systems: Design, Implementation, & Management 11th Edition
Anything that uses MySQL as a teaching example is just plain wrong.
Why? It demos the basic concepts fine. Maybe they can use MariaDB instead?
It also encourages students to use MySQL. If they were concerned with cost, they should have just picked Postgres.
direct link to the PDF : http://www.postgresql.org/message-id/attachment/43080/Postgr...
This is the PDF in English (via Google Translate): https://www.metachris.com/download/PostgreSQL_Oracle_en.pdf
So their argument is that Postgres is not feature complete with Oracle due to this new law? Yeah, that's not going to fly. All the register needs to show are the few things Oracle can do that Postgres can't and then Oracle will only be allowed to be used in those limited scenarios.
Oracle gets desperate ;)
This has been Oracle's (i.e. Larry Ellison's) sales and marketing M.O. since forever. Read up on why Raymond Lane left the company. And sad part is it works.
Only till it doesn't. One day they'll try this tactic and discover that they've burned so many folks early in their career that a majority will see through the tactic. Or alternatively decision makers will consult with staff that advise them directly and THEY will have been burned.
And the third thing that can happen, which happened with a friend of mine, is that a really bad solution is implemented at a very large ongoing cost, the executive who made the decision leaves (which is what often happens with incompetent executives) and their replacement walks in, sees the disaster, doesn't care about saving his predecessors stupidity and decides to remove the bad solution, and makes sure that the vendor who caused the headache goes to the bottom of the pile when it considerating them during tenders for new business.
You know what they say: it costs less to keep existing business (especially in a saturated marketplace where you are the market leader) than it costs to drum up new business.
Believe me, this is a very short to medium term sales solution. When it goes wrong it's not easy to recover from. When competitors start taking market share from Oracle they'll find it very hard to recover their market share without immense upheaval and systemic change throughout their business. Microsoft learned this the hard way. Oracle's time will come! Can't come soon enough.
I was interested in reading up on this, and found this article if others are interested: http://www.peoplesoft-planet.com/anatomy-power-play-ray-lane...
Thank you guys for all thoughts here (a lot of interesting ones, as usual on HN)! I'm going to analyze them and create a compilation.
Meanwhile PostgresPro (extended PostgreSQL version, distributed by Oleg Bartunov's company "Postgres Professional") officially included to the Russian Software Registry: https://reestr.minsvyaz.ru/reestr/65273/ [ru]
~~ Nikolay Samokhvalov
Are there consultancies that specialize in Oracle -> (Postgress, MySQL, SQL server, et al) migrations?
I mean, I'm sure there are but, when coupled with a skill set that helps you counter "license reviews" that could be quite a business.
Fun bit:
PostgreS "ships" a Java 8/JDBC 4.2 driver, Oracle does not.
boo, they are afraid
First they ignore you, then they laugh at you, then they fight you, then you win.
(Gandhi)
This.
My first reaction to the news is that it is a clear evidence that PostgreSQL is now fully on par with Oracle in terms of everything average IT companies need to be concerned with. If I were Oracle and my product is still ahead of PostgreSQL at least in some areas, I wouldn't be so upset.
Yeah I was thinking the same, if it's clearly subpar then there would be no reason to send the letter in the first place. That's logic managers without technical knowledge can understand.