Of course it's not that old, but considering 1992 is the year I started to play with computers as a kid, that's older than I expected, at least for me.
I've used internet for the first time when the The Register became an online publication.
IBM must have felt that there is a market, and one that would be able to justify the upgrade. Some spreadsheet must have the number that says "This is how how many core at this price point, where this product makes more sense than dealing with Oracles licensing".
The article does conclude with this interesting observation:
Be aware that the SE2 license does not offer access to all Oracle database features.
Oracle's EE license offers access to more, and more powerful, features.
Which makes IBM's statement of general direction a little odd:
why create a powerful CPU for a low-end database?
Big Blue still has not responded to our inquiry...
That seems like something that happens with ad-hoc customers not so much with enterprise customers who have purchased support plans (for this reason among others).
I don’t have access to the text of the license, but I almost guarantee they have a clause in there that specifically says they are allowed to change it. Just like 90% of the terms of service.
My LG TV just stopped me using anything on it until I pressed agree on the license, nothing to stop Oracle or anyone doing this, in fact I guarantee they are drafting the new license now
I remember the old joke about oracle pricing spreadsheets. Lots of sliders to adjust the parameters. But no matter what you did the price would always increase.
We've had a bunch of VMWare clusters consisting of 5-6 servers each, maybe something like 2x16 cores or 2x32 cores for each server and 384 to 768Go of RAM, I'm not sure about the specifics.
We had VMs running a few Oracle databases, nothing much more than 2 cores 16Gb or 4 cores 32Gb, the vast majority (90%+) of our databases were running Sybase, and half the resources were for the app, so something like 5% of those clusters were Oracle dbs.
We were paying Sybase maybe 100k a year for the entire datacenter, and so we expected to pay something between 10k and 100k for Oracle (remember, for 1/20th of the compute and with a developer license because we were not hosting client production).
We asked for a quote to Oracle, they came back a week later with a 520 million dollar bill, more than the revenue of our entire company. It was never paid of course but this shows how absolutely ridiculous their template is for billing. The reasoning is well known now, a 2 core database can run on potentially 6 servers * 32 cores * 2 threads per core = 384 possible cores, so if you have 2 or 3 databases you can potentially get billed a license for 1000 cores (and actually running 6 non-production database = 0 service on their part because if it breaks you just redeploy it, it's faster than opening a support ticket).
Part of that is playing the game; Oracle knows to come in high on the quote so the CTO can negotiate them down from batshit insane to simply eye wateringly painful. Looks great on the year end report!
That's why there are consulting companies specialized in Oracle licensing. Just hire one of such consulting companies, instead of dealing with Oracle directly.
I may be just a simple engineer with mostly postgres experience but why in hell would businesses go through all this pain for oracle's db product when there are all sorts of alternatives? Is the product really that much better?
I'm sure someone will chime in with direct experience wrt Oracle, but most cases where it looks like many companies are overpaying by >5 times for a certain service or product compared to the value it delivers are similar. Such decisions are commonly made (or at least signed off on) by upper management who are paying so much purely for CYA reasons. The old "Nobody ever got fired for buying IBM".
Another related but distinct reason is box-ticking purchasing decisions. Decision makers who 1. aren't the end users 2. lack technical knowledge 3. are overconfident and overweigh their own opinion, are likely to decide between products purely based on the number of feature boxes it ticks, regardless of their real-life usability and usefulness. Companies like Oracle know this and cater to it. They don't care if a new feature is useless or poorly implemented as long as it creates a new box that makes the decision makers 0.5% more likely to go with their product.
Always thought this was a joke until I tried oracle cloud. You could create SKUs that don't exist on the PDF price list, multiple versions of said PDFs and ultimately the most reliable source of pricing was a community compiled list on some shitty forum.
200bn market cap company ladies & gents
In fairness though - they have a great free tier (if you can live with the arbitrary account terminations)
Rule n.1 of sales: you should charge the highest price the customer can bear. By keeping things fuzzy, they can bamboozle you at will, making you pay not what you expect, but what you can.
Same, it all depends on your costs, if you are SaaS and have a dev team that knows Oracle then why not use it, it's not going anywhere, it's hugely reliable and it will definitely scale up vertically as high as anyone. And plsql is a much underrated technology.
On the other hand if your product involves on-site deployment then Oracle is most likely not going to stack up.
Probably the same people still do, but the tech industry has expanded, and most of the new things (startups) are better served with a Postgres cluster.
When I was a bit younger I worked on quite some high profile (for my country) web apps. Think e-commerce, travel. Couple million users. We used Oracle on big fat metal server stacks for this.
I honestly thought this was needed because RAC and some other stuff. Uptime!
Now, a little older and wiser, I know all of these projects would have been fine on Postgres on some hosted provider.
When companies were moving to the internet in my part of the world, second half of the 90s, their preferred stack was a Windows NT 3.5 server, Java and an Oracle DB communicating by file exports/imports with some AS 400 or an actual IBM mainframe.
Most banks, telcos, insurances, many private and government sectors are using it, and will keep using it for decades to come. The people who think otherwise don't have much experience in real world (TM) outside of startups and small shops.
I don't think that ie Postgres has immediate onsite 24/7 support globally, which is much more important for business than pure performance per dollar or similar metrics and they are happy to pay for it. Also trying to find top notch DBAs in Oracle vs Postgres gives, at least here in Switzerland, very different numbers of resources available.
Ie for banks its usually part of their core banking packages and performance-wise not much can replace that (but you need a small army of plsql experts to tame it, although there are plenty of those in the industry).
Also, I'm not sure that you can buy off the shelf hardware from top vendors which guarantees transaction performance and reliability for PostgreSQL either.
HPE, Dell, IBM, Oracle itself is building and selling systems designed and optimized for running Oracle databases, for at least a decade now?
Allegedly 90% of the world's biggest banks run their core systems on mainframes. Oracle did offer their database on mainframe but stopped and the last supported release went EOL in 2013. There's still possibly extended support being paid for, but sounds like they possibly don't have a lot of the bank-on-mainframe market.
I wonder what those banks use for their databases. IMS or DB2 maybe?
Not so say your comment is wrong, there are thousands of banks and average assets of few hundred million. Unlikely they would fork out millions for mainframe setups. Majority of those could be on Oracle as you say.
I know that one of our biggest national banks still run on mainframes for their core banking infrastructure, but there's so many satellite systems which are way more modern and use separate systems and servers.
In these cases generally DBs are migrated to external clusters of their own (like HPE Superdome, Exadata or similarly tailored hardware) and connect via IB or IB like low latency, high performance networking.
AFAIK, the bank I'm talking of is working with "Don't fix what is not broken" motto, and only move what's necessary to modern or external systems.
Huh. You mean the bank running the mainframe has moved database to a cluster of other systems? What does the mainframe run then? Business logic / applications in COBOL or ABAP or whatever?
IBM at least used to be the second biggest Oracle reseller/consulting/support shop, after Oracle itself. IBM just wants your money and will give you anything you ask for.
It isn't the chip architecture that people are buying. It is the hardware that gets asymptotically close to Tandem- and System z-like features that you cannot yet get on x86- and ARM-based gear. Lots of HN folks like to throw shade on AIX, but if you have someone who is dead serious on obtaining near-mainframe-grade RAS on "a Unix" and is willing to write the checks for it, the check is smaller on POWER systems running AIX than trying to effectively roll your own under x86 or ARM systems running whatever Linux distribution you care to choose.
It just so happens that in the vast majority of use cases, x86 or ARM systems running Linux are good enough for the business purposes. The first few times you run into the situation, you'd be amazed what losses and risks business will tolerate when faced with the costs to mitigate that last 0.1% of profit optimization.
In absolute numbers there are way more commas than the average HN'er retirement portfolio in that last 0.1%. But when it will cost almost the same in the first 3-5 years of migrating to AIX than that number, the IRR payout timeline is way longer than most businesses will tolerate. And most managers are savvy enough to understand the teething pains in the meantime are a career-limiting move.
I mean I get it if you want to run AIX for some reason, but with Oracle RAC, you get the availability basically with commodity hardware - that was the whole selling point of RAC initially.
Oracle RAC is a great solution for Oracle database availability. AIX solves the generalized problem of bringing RAC-like availability to general monolithic applications. Different use cases, each with their own particular strengths.
As much as I am loathe to choose Oracle as a database when solution designing, there is no hesitation when I run into a use cases where nothing but Oracle can address the performance, feature and/or availability requirements, and Oracle RAC comes along for the ride many of those times.
However, anytime I see someone demanding mainframe- or POTS telephony-grade availability outside of an Oracle RAC, and they’re willing to spray the money hose at the problem to get it quickly nearly out of the box instead of underwriting an open source research and development project, I first reach for AIX on POWER System iron to try out the feature fit.
I’m shameless in flirting with whatever tech stack will meet the business and engineering requirements.
IIRC they did something related a long time ago when you could get a 8 CPU box which was physically restricted to 6 CPUs purely so that it didn't fit into the "can have 8 CPU" Oracle license.
About 2/3rds of the servers we sold at the time probably went to run Oracle and it gave us a massive TCO (total cost of ownership) advantage compared with other vendors, especially as the POWER chips were faster than the competition too.
When most of the cost is in the software, the choice of hardware can still make a big difference.
Wide SMT/CMT is also favored by Oracle's billing system - you aren't billed (afaik) per-thread but actually per-core, so 4-wide SMT or 8-wide SMT gives you an advantage over x86's 2-wide SMT.
In theory the "core multipliers" are supposed to offset this, so a "core multiplier" for POWER or SPARC should be higher - but Oracle also likes to push you towards their own products, so there is a bit of a "bundle discount" particularly on SPARC's core multiplier.
The last SUN/SPARC server I bought (maybe 5 years ago?) had the same thing going on. 1 cpu, huge number of cores. Sun was already owned by Oracle at this point, so I would guess they are not as concerned about IBM's move as you might imagine!
Yeah, I seem to recall the machines we were buying 6 years ago (Oracle-branded machines, that is!) were 288 threads... out of something like 6 processors.
The article was posted long after business hours at IBM. You posted your comment long before business hours at IBM.
It might amaze certain types of people to believe that IBM doesn't have a fleet of PR people sitting around at midnight the week before Christmas to respond to rando online articles.
It's entirely possible that El Reg submitted its query to IBM a week ago and waited for a response that never arrived. But considering the state of internet "journalism" these days, usually they send a Twitter DM and if they don't get a response in the time it takes to finish a Starbucks, they consider it unanswered.
I believe "low-end database" wasn't a knock at Oracle either. The pricing advantage you get with multiple cores for a single socket applies to standard edition which is their low-end database product. I have never seen it used in production.
Serious question: Can someone explain to me why would someone still be using Oracle in 2022 when we have equally capable or even superior open source alternatives like PostgreSQL, which have none of these shenanigans? Maybe legacy software that would be expensive to rewrite?
I'm a backend developer and I regularly kickstart systems (and get to choose which components we are going to use in the stack) and I fail to grasp in what kind of project I'd need to be to even consider "this might need us to bring Oracle to the table". Again, honest to goodness question, looking to learn. Is there some edge to Oracle compared to the FOSS stuff that I'm not aware?
I know why Oracle does this, but I can't comprehend why the customer's senior leadership and the owners tolerate this embezzlement, which hurts the company and is criminal.
While there may be reasons to pick Oracle for greenfield projects in 2022, I suspect most of the business comes from companies which have been on Oracle for a very long time and have huge amounts of critical data in it. Oracle has likely calibrated their pricing so that it's always slightly cheaper to stay on Oracle than to move elsewhere.
Doubt that calibration is the impetus to stay with Oracle. Most C-suites are quite dumb when it comes to technical stuff. They also don't value technical people more than it is just a replaceable organic "machinery". I have seen many instances IT advising moving away from Oracle but every additional budget to do so (even if it is just time and no direct dollars involve) even if just to test feasibility is shotdown. Meanwhile hundreds of thousands of dollars they gladly pay as long as they freely grumble that their staff too dependent on Oracle tech.
> provides stability and continuity and is 100% the right solution (cost inclusive) for some hard problems.
What kinds of hard problems? I think a big part of the discussion here is centered around the fact that aside from legacy software that's exclusively compatible with oracle (in which case you're stuck with it) there isn't yet a compelling reason to use it otherwise vs. eg; postgres w/ a support contract or even something hosted.
FWIW a lot of things people have tried to shoehorn into a traditional RDBMS can be accomplished other ways too.
Probably the vast majority of problems where Oracle is the right solution are problems where Oracle is already in use. That's actually a large market. It's unlikely that new, greenfield solutions have Oracle as the best choice.
But, let's say in 15 years -- people have some hideous brownfield AWS legacy application -- is it worth it to rip and replace an existing block of working infrastructure just because there's some new hawtness?
I had a friend working as a project manager for company using oracle, i asked him the same question, he said they looked into it - if they could get rid of 100m bill they would be happy to use anything else but some functionality was not really there.
Given this is the platform we interact on, you are likely a competent developer right? Would you apply for that job?
Non-tech company seeking competent developers to move 100s of thousands of lines of code and sql scripts written by juniors over twenty years from Oracle to Postgres. Must have plenty of Oracle experience but also Postgres experience. Will have to coordinate with DBAs across business units and coerce them to help you in (eventually) axing them.
There is no amount of money that would get me to sign up! And also I wouldn't trust the current team to interview and recruit competent developers!
Heck yeah I'd sign up for that! Honestly, this is the kind of work that can sustain an entire consulting firm.
- It's specialized, so you can charge more for it. And I mean come on, we're saving you millions of dollars. I can charge you a LOT and everyone still wins.
- It's repetitive, so you can train people to do it and then start earning margins as they replicate the process across the organization.
- It's even fulfilling. Yeah, I said it. Would you rather go work on another to-do app in [pick an obscure fruit or animal]-framework for your blog? Count me out of _that_ crap. Any Oracle DB you work on in the wild is going to have an impact on thousands of people--a positive one if you do your job well.
"Project manager". That says it all. Do you think existing oracle DBAs willing to assist to kill their cushy jobs? Even if not complete replacement, partial replacement like postgresql would easily slash that 100m bill by several millions.....more than enough to hire developers to replicate those missing features.
I'm not defending Oracle here--far from it, as their sales and follow-up audits when you ask for support are purely predatory--but a tiny fraction of companies are in a business where "hire developers" is a feasible or reasonable approach to a problem. You might argue that software runs everything, so every company of a size where it's reasonable to even consider something like Oracle is in that business whether they want to be or not, but that's just not how it works.
Because despite its predatory pricing and quirks, it's actually a pretty good database?
There's an enormous amount of larger businesses for whom the database _is_ the business. (Well, databases plural, they'll inevitably have many.)
I've worked for places where the vendor of the software that sits on top of the DB is either defunct, gone AWOL or too pricey to consider upgrading what ever version of software we were using.
I worked one place where we had to large hadron collide data from Sybase and Oracle together. Live. No batching. The whole thing had to plug into some decades old Delphi crud apps + some financial software somewhere else.
Oracle + dblink made that possible. It even, as I recall, did proper two-phase across the dblink. I merely queried -- yes, I know PG kinda has the same feature nowadays -- across the database boundaries and wrote some pg/Sql to make things work. 10 minutes and $10k (or w/e the Sybase connector cost) later and we had a POC, and later that month, a working system.
Pretty? No. But it worked well, and two disparate software products written in different eras that were never meant to talk to one another now did. And it saves us millions in licencing + bespoke software and expensive consultants.
There are few limits to what you can do with Oracle, and that is its strength. When you have weirdo requirements, you can probably do it with Oracle + some skilled DBAs and be assured it'll still run in 20 years.
As for PG: I love PG, and use it for everything greenfield. But its replication is still a planet-sized joke. There are more competing methods and processes than there are JS frameworks. With Oracle, you've got DBAs who know this stuff inside out, and it works, and it has a million-billion ways of matching the needs of your business. With PG? I don't even know who to call if things are up the creek.
It's not really a good database. By most actual database-related metrics, it's worse than most of its competitors on durability, performance, cost, etc.
It's just one that has people to call when it breaks.
I generally mean the free competitors, but also the "NewSQL" DBs, cloud company offerings, and data warehousing companies. The traditional "enterprise" databases like MSSQL and Oracle all look kind of silly (from a technical perspective) in comparison.
> I don't think that's true. RAC/data guard are solid, and I don't think have any competition.
RAC does not indeed.
But the equivalent of an active data guard can be setup in minutes (even less with the right tools) with Postgres. I am sure this is possible with other databases as well.
RAC's PostgreSQL-based competitors are CockroachDB, Amazon Aurora, and Google's AlloyDB. I'm sure there will be an open-source PG plugin that does the same thing soon. These are all scale-out, globally consistent databases. Also, they have fewer bugs than Oracle.
Great insights there. I would add that enterprise CIOs paying Oracle through the nose are not idiots, and would have analysed the tradeoffs. Of course there is no company that does not have a migration plan for its workloads but, like mainframe migrations, this stuff is not easy and it could very possibly not make sense.
Indeed. It's easy to laugh at CIOs and CTOs, but many of them try their best with the options they have available.
I'm reminded of this anecdote I had with a colleague a while back. He was railing against MS Exchange's rise back in the 90s, and how Novell Netware was better and that he was forced to switch their org to MS Exchange, back then, solely because "His CIO read it was the future in a magazine."
The magazine wasn't wrong. NetWare was a real mess architecturally. The core file and printer sharing features worked great. But as an application server for email, database, or anything else it was a dead end. No memory protection, no real multitasking, bizarre proprietary API, terrible developer tools. One of the major relational database vendors did actually port their product to NetWare but it was a flop in the market.
Novell eventually tried to catch up by grafting their proprietary networking features onto Unix but that was too little, too late. The CIOs who started migrating off of NetWare early were the smart ones.
I agree completely. But man, it was pretty amazing as a file server for DOS machines. You could boot a roomful of diskless PCs over ethernet from a 386 server, and for most uses the speed felt like you had a local hard drive in each one.
I ported a C++ server and struggled with the only available C++ Compiler for Novell (Watcom). Debugging meant staring at core dumps. Novell bought SUSE too late.
For a large set of problem spaces you can replace "oracle" with "cisco" or "microsoft" or "AWS".
These companies demand a premium over "rolling your own" or "integrating a pile of better at solving a specific problem" products. In some cases the premium is well earned, in others it's just rent-seeking monopolist behavior, depending on how mature the product space is.
Nitpick: Rent-seeking is an economic term that describes an actor that provides no value for end users. It is not a synonym for someone who rents you something.
It’s confusing because it can apply to landlords who also seek to restrict supply, and people then conflate the former with the term.
Of those companies listed, maybe you can finger Oracle for their shenanigans with Java.
The far end of this continuum is CA Technologies where they buy products with an entrenched customer base and squeeze them for money while putting the product on "sustaining engineering" (aka hospice care).
On the continuum of "innovative product solving hard problem" to "Rent seeing monopoly" AWS is still in the "build the mouse trap" phase while oracle's half way to CA.
Of course, license true-ups in my experience are allowed the latitude of, "Whatever you can get them to agree to". I've heard a few times Oracle sales folks trying to pressure companies into buying licenses for all physical machine cores for the host underneath their VM's in the cloud. Which is, frankly, malarkey and not even supported by their own docs. (Apparently this is how it is licensed on-prem if you own a VMWare cluster or something, but they carve out an exemption specifically for cloud hosting in their docs - but they try anyways)
It reminds me of people who pay through the nose for cloud. They've done the spreadsheets and DIYing servers and infrastructure and hiring the people required to administrate it often comes out as more expensive. It's much worse for companies that are not tech companies with lots of in-house IT experience. They often lack the institutional expertise to even hire the right people to manage a DIY infrastructure. So it makes perfect sense to outsource to AWS and pay what seem like very high costs. You're not really buying the compute. You're buying the management.
My only experience with Oracle was we were using it at a startup at the turn of the century. I got tasked with asking them for a quote. They came back with one but offered pretty strong technical support. My boss, wise in the way of databases indicated that their support would involve using there apis locking us to them as opposed to the odbc drivers that let you switch databases easily. Those odbc drivers weren’t great on Linux at the time.
The startup ran out of money a couple months later..
One 'feature' Oracle has, that is very important to some large companies, is that they offer truly full stack support, from the hardware up to the application layer. If I buy support from some PG developers and they diagnose that the problem is actually with my RAID controller firmware or a bug in my inventory management software, will they still take responsibility for fixing it?
Edit: Another aspect is how long will it take for one of those PG core developers to show up on site? Oracle already has a team of support engineers (either first or third party) in most major cities in the world.
Oracle Support has gotten absolutely terrible over the last four years. I support a full Oracle stack, and seeing all that beautiful Sun engineering turned to sludge because of poor support is really sad in many ways.
> With PG? I don't even know who to call if things are up the creek.
There are plenty of companies offering commercial support contracts. Most of them are also active contributors to Postgres so they do have the ability to create bug fixes and patches.
Existing systems. Migrating large mission critical systems with lots of SQL is surprisingly complex and expensive. Not only will they be tied to Oracle they are probably tied to a specific version that costs a fortune to be maintained.
I did a migration from Oracle to PostgreSQL and saved a ton of money. I'm happy to say that automated integration tests for everything made cutting over not too bad. The other thing that helped was PostgreSQL consultants to plan and execute the data migration.
It speaks to a marketing failure anyway. Shouldn't we be getting reminded of whatever that situation is where an Oracle database would be useful? Even if it's just compliance or political ("if you want a military contract, you'd better say you're using Oracle").
I remember years ago certain features (materialized views, maybe?) were Oracle-only, but Postgres has more of those now and I'm not sure what's left.
The answer I got from a head of IT of a medium size traditional company is that they have shitloads of processes, scripts, server calls all running without anyone of the people who wrote them on board anymore… they all work perfectly together, transactions are always guaranteed.
Their job is simply to understand the machine itself rather than the software and make sure they keep it running
1. Sales. Oracle will sell you not only the database engine, but also spec hardware, Cloud Control and similar things. Essentially they sell consulting and appliance in one package. This can sound like a good deal to management, detached from boots on the ground, in larger companies.
2. Support and guarantees. Postgres comes with no exrpress liabilities while Oracle offers some guarantees. Data loss being "their problem" can be a nice clause for business people.
3. Legacy projects. Migrating schemas between engines is usually doable exercise. Migrating application logic can be multi-year project for a decently sized, capable team.
3.1. Cross-project dependencies. Exchanging data via database rather than APIs is more common than one might think. Changing database engine in such circumstances becomes exponentially harder the more projects are involved.
Large companies typically run ERP and related systems on Oracle. Supply chain, finance, hr etc. These system were often implemented decades ago and companies are reluctant to poke around that.
It's also very likely implemented by some consultants and I wouldn't be surprised if there's a lot of weird Oracle specific functionality used. Convoluted stored procedures that nobody understands and nobody touches because then it probably breaks.
Oracle also has a very aggressive sales organization. They will defend their accounts. That might be with carrots like discounts. It may also be with sticks, like licensing audits.
Anyone who hasn’t used an ERP would be amazed in good and bad ways by it.
We think people using the slightly older version of HTTPS is weird - ERP systems are often so old that the grandkids of whoever started writing it are retiring.
Oracle has things like “pretend to be a version of the database from 20 years ago so this weird load-bearing piece of software doesn’t break.”
The only thing I know of that comes close is Windows itself with its shins and Linus’s absolute refusal to break userspace.
There's a business model of "Give us enough money and we will solve all your Foo related problems." Oracle has a widget to solve any IT / Data related problem for a naive enterprise who's core business is not IT. One vendor, one bill, one support contract, assurance that if your board asks you to do some other thing (we need a thingawidgit for compliance for our peoplethinger! Oracle's got peoplethingerwidget !). Amazon's AWS is the same for IT these days. Need a queue? We've got 3!
Interestingly, oracle where I work, where we have a lot of oracle, was only 2-3x the cost of our slack license. So either slack was absurdly expensive or oracle isn't actually that expensive, or possibly both. But we only use oracle DB + some support oracle DB widgets, not the whole oracle ecosystem. And for us, the oracle DB and the widgets have been actual facilitators in our enterprise. Need a CDC system? They've got 3!
It's an enterprise thing. I have seen these dynamics with database vendors: databases are sticky, clever license agreements.
A commercial database vendor system gave us several free licenses (or cores or something like that) for their platform as part of a deal. Sounds good at first glance. But when you shut down an instance, that returns a license to the free pool. As a result, nobody has incentive to ever do this work. Indeed, if you did free up a license, one of your colleagues might notice and use it on another project. After all, it's free.
The way that databases are commonly used, they become an informal API for communication between systems. One codebase writes an order to the database, another reads it, and another reports on it. Once you this situation, it is difficult to remove. That would require coordination between multiple teams, and it doesn't generate revenue.
For a piece of software like this, it only needs to get in the door once.
I've seen things written in Oracle 20-30 years ago that I've still not seen PostgreSQL or SQL Server do.
An example? A full credit card processor in stored procs. I really mean full, it handled the call outs to financial providers, managed the 2-phase commit, replied to the app, all within a single call (Stripe API is the closest I've seen to this in the 30 years since).
It remains possible to do things that are crazy and powerful, very quickly.
Whether the people here would want to is a different question. But if you are in a large corp and Oracle is available it is easy to do crazy things.
Once these things are done, Oracle is going nowhere. They are now in your system for the life of your product.
Oracle does have quite an impressive set of capabilities. However, for every company that absolutely needs Oracle, there are probably 10+ that don't and could work fine with PostgreSQL or SQL Server today (though maybe not 20 years ago.) I worked in an Oracle shop early in my career, and would never want to go back to that again.
Curious: what is the version control story like for stored procs? The two that naively come to mind would be
1. Organized in some regular repo with some tooling to deploy/sync
2. Some way of tracking versions _in a DB_ and some magic set of queries that can deploy from said DB.
Not only could you do that in Postgres, but you could do it in a real language of your choice. The reason you don't see it done is because the people who choose Postgres over Oracle know that it's kind of a terrible way to build it if you care about long term maintainability.
That method of building fossilizes quicker than quickcrete.
Usually it’s either because your company has built a practice around it, more commonly you need Oracle Financials, etc.
Once you have the Oracle infrastructure for Financials, PeopleSoft, etc, the question is does it make sense to stand up services around the Oracle portion. The cost of the people to run Postgres or MS SQL server may be more than the marginal add of Oracle.
Awesome. I have probably dozens of posts over the years about why one would choose Oracle, so I won't rehash it all right here, but I'll link some relevant ones. Briefly though:
> in 2022 when we have equally capable or even superior open source alternatives
This isn't really true. Postgres is a truly excellent RDBMS, but most people compare it at a rather superficial level, because many use only very superficial features. If you need to insert, select, update, and delete, you have a lot of compelling options. (This can easily veer off in another direction, but I astounds me how many people shun the database and chose to reimplement innate features in procedural code outside of the database.) For example: Oracle has an extremely richly featured, powerful, and stable data warehousing feature set that has no open source analog.
A lot boils down to build vs buy. Some places build because it's exciting. Some don't even know that the thing being built has existed for three decades. This applies equally to open source. It's entirely possible that a materialized view will obviate your whole external caching infrastructure.
I imagine that some of the choices to lean into the RDBMS specifics also come from application architectures and data complexities.
If you have a few large monolithic applications that share multiple schemas (so no single-owner), and you then need to do classic OLAP, OLTP and cubing, you're essentially stuck with database solutions from the same era. Same goes for record-oriented software and mainframes or low level rtos software that requires real mode. The requirements never stand on their own (which is pretty much what you wrote anyway ;-)
If a BI solution can do gRPC to a few specific services that contain the datasources for the dimensions you need, then nearly all OLAP-native features are irrelevant. It also means that the dynamic resource usage means that your overall cost in terms of energy and money are significantly lower.
The big 'if' in all of those is going to be 'does the organisation have the skills and the willpower', and often the answer is no. Because hiring some MSP to do your BI, data management and have some single vendor do your ERP, EHRM, ESB on top of some RDBMS "sounds" good and means it's their responsibility, and when a user then sends them a support ticket about how crappy their UX is and how much the workflow sucks, they will get ignored and somewhere in some expensive place, old grey men shake hands on yet another successful quarter ;-)
Diplomatic preface:
I think Oracle is a pretty darn good database just so thats said.
Opinion:
Why would you say there is no open source analog to the Oracle DWH setup? CitusDB has been able to replicate the mix and match of OLAP and OLTP for quite a while now. In my time as an architect in MSFT we were competing (and successfully too) with CitusDB and Postgres against bespoke complex Exadata setups already a few years ago, and CitusDB just keeps getting better as they integrate more and more options for working with columnar data.
Oracle just straight up ignores all the goodness that has come out of modern operating systems and still tries to peddle Exadata setups with custom hardware nodes and whatnot when a large swathe of those problems can be solved horizontally instead of vertically.
If your business is a thin layer around a finely tuned Oracle setup then ofc it becomes pretty stupid to suggest moving off that and into Postgres in any kind of less-than-five-years project. I would say though that for new projects it is most likely cheaper to either hire postgres experts to replace your oracle experts or just let your Oracle gurus forget all the vendor specific tuning you don't really focus that much on in Postgres than it is to pay for Oracle.
Sorry for the late response. Citus certainly does keep getting better. Its parallelization is a little different but given a system designed to use it, I'm sure it'd be just as good as Oracle. Its tenant sharding is a killer feature.
My argument never has been that it's purely a feature play; in fact, I think RDS made Oracle far more compelling, because I got to offload the majority of the day-to-day. Now, with citus on azure, yeah, it's pretty compelling on the operating cost side.
> If your business is a thin layer around a finely tuned Oracle setup then ofc it becomes pretty stupid to suggest moving off that
Right. It's really and end-to-end thing. Oracle serves pretty much every significant business problem. It has a giant API and huge function library that I can use to implement pretty much whatever I want. Then, I can turn it over to the auditors, who know it and understand its operations, so compliance is relatively easy when it comes to things like HIPAA/PCI/FERC or whatever.
It's not just about tech. It make a lot of sense for a lot of businesses.
Now that I'm not as heavy in regulatory environments and more in science, I think I'd be very happy with the offering. (In fact, I am actively using postrges, and not actively using oracle right now.) I might miss some of the in-built reporting functionality that Oracle has, but I'd have to have a look at the very latest offerings in that area from citus.
Not to poop all over what you said, but I went through the history of some the previous comments you made to communicate the power and features of Oracle and I have simple question to ask you: Is it possible you are unfamiliar with the full features and capabilities of Postgresql?
You seem to be talking about what Postgres doesn't have as an argument for choosing Oracle. This hasn't really shown why postgres was a poor choice or why Oracle was the better one.
What thing, I looked briefly through your link and didn't see anything that I can't get via Postgres. I'm sure there are probably some very niche things that work differently and make Oracle a compelling choice,n but you haven't actually listed one yet.
They for some reason are refusing to prove the affirmative of their statement that there are things Oracle can do that Postgres cannot; which leads back to my original question, that they may simply not know Postgres.
1. oracle's query planner/optimizer is smarter and more efficient, especially with complex query. postgres for quite some time did not do well with nested, lateral queries with CTEs that include views - it's performance would randomly degrade on complex queries, which is rarer thing in oracle world.
CTE expression is an optimization fence in postgres, which is not the case in oracle.
2. oracle does not need vacuum, unlike postgres
3. postgres has problems with many concurrent connections, thats why you need workarounds like pgbouncer. Oracle doesnt need that.
And same picture with almost any other feature - it is sort of "works" in postgres - but with crutches/workarounds, while in Oracle - stuff just works out of the box.
You dont need to search and install some obscure opensource extension to get the thing you want working, like you do in postgres world. and then keep updating that extension with every new version, etc
Just curious how you are certain of the better performance and behaviour of Oracle given that Oracle does not allow disclosing of benchmarks without prior consent from them?
At the bank I worked before 2019 at I was on a advanced analytic team, we had this amazing teradata database and then there were these insanely fast (yet older) IBM DB2 databases and then there was a few big oracle databases.
We did amazing things with teradata + DB2 and then a leader who was tired of multiple databases asked us to vote, we chose teradata so we went with oracle and the migration was so bad I left.
This is most probable. Oracle specialists tend to be people who have been working with Oracle and Oracle only for the past years, if not decades. They could never possibly have a knowledge of the full functionality of Postgres, which coincidentally changes rapidly.
Not the same percentage of them. Postgres has been used for a shorter time in large companies. Many experts in Postgres were previously experts in another DBMS.
In contrast, most Oracle DBAs/Engineers publish the fact that they have only used this specific product during their whole career. They seem to be rather proud of the fact, actually.
Can you help us understand why one would use a data warehouse from Oracle as opposed to a plethora of arguably far better options like snowflake, BigQuery, and so on.
BigQuery can cost a fortune. Our data engineer messed up once by not time partioning the DB and it racked up a ~10K USD bill in a month due to the high number of queries that were running on it.
As a former PM on BigQuery, I'll offer my perspective:
- I agree that, by default, the on-demand pricing model is pure consumption, and folks can and do mess up sometimes.
- I had a habit of refunding folks when they asked, and if they made obvious mistakes, even though it took me an average of 3-4 hours to process each refund.
- BigQuery has cost controls to prevent runaway costs, sounds like you must check it out ASAP
- BigQuery also has a DDL option to require users to include a partition filter predicate in queries
- BigQuery also has flat-rate pricing, on which the vast majority of folks above SMB on. There are no runaway costs with this one.
I think generally BigQuery is a great example of an extreme serverless consumption-model. You have thousands of cores at your fingertips, and, well, if you do something that overuses, you are allowed, but you do pay for it.
I am a dev, so the pricing part would be in the responsibilities of the client's GCP project we were using along with the architects. The flat pricing was something I did suggest when we on the call discussing the above mentioned situation, but it was ignored.
However, I agree its a really cool tool, I have not worked on the ETL side of things, but we use BigQuery in almost all of the projects I have been on, my teams usually needs to figure out the right query to determine key KPIs our clients usually ask for and the SQL is really helpful.
Aren't those both cloud only products that require you to send your data to third party servers (quite possibly in another country)? In some cases that is a hard no.
That's fair for some (I say niche) use cases. Both BigQuery and Snowflake have a plethora of security and compliance features (including ML-driven automatic PII identification, masking, and categorization), and they certainly do not move data to another country without your explicit direction.
> This can easily veer off in another direction, but I astounds me how many people shun the database and chose to reimplement innate features in procedural code outside of the database.
I've done this from time to time, and it's usually a question of the database clients are much easier to scale than the database. What can the clients do to reduce database i/o and cpu, because I can add more clients easily, but turning a database into a cluster is relatively more difficult, so database machines have to scale up instead.
Otoh, the limits of machine scaling are quite high these days. You can get a single socket epyc with 64 cores and 3TB of ram and tons of lanes of nvme.
Ironically a factor in that scaling question historically has been cost of the database license. You may be able to technically scale the database server to handle the load but it will generate a multiple person-year type cost inflation of the license fee.
Leading us perfectly back to the topic of this post!
> Awesome. I have probably dozens of posts over the years about why one would choose Oracle, so I won't rehash it all right here, but I'll link some relevant ones
Unfortunately Oracle has become far to aggressive in lawsuit for a lot folks like me to ever be comfortable building anything with their products. Same for SalesForce, I just killed a project that we wasted $200k on but we'll save a lot more killing it rather than becoming dependent on SF next year. Oracle gets you over barrel, then charges you through the nose when they know you're in too deep to move. Their products are great, but the companies themselves are too dangerous to work with.
My first time using Oracle, I was trying to migrate magazine articles to a different DB system. Oracle "helpfully" and silently truncated the magazine content at a certain size, leaving most of the articles unfinished. The Oracle experts were incapable of producing a dump or report of the raw articles. So, I tried myself. I tried multiple tools, and every single one would truncate the field regardless of my settings, except for one. The Java ODB driver gave me the whole thing. So, I had to write a Java program to extract it for me.
In the end I learned that Oracle can't even output it's own data properly, even with the help of experts. I also got to learn what installing Oracle software was a really like (it was brutal).
So, no, I would not recommend Oracle to anyone, ever.
1. I worked with developers trying to implement a UI using Oracle's app-builder of the time (Oracle Forms? I don't remember). The devs spent an entire summer, with Oracle support, just trying to get the system set up and configured to build "Hello World." They gave up and we abandoned the project.
2. I needed to install an Oracle product on my computer. I had an Oracle provided CD. The install was non-obvious: multiple install files with multiple options and ways to get it wrong. On the CD was a set of help files, with an app to view them. The app did not default to showing the help files: you had to select which base file to start with. The choice was not obvious. There were broken links in the help system -- meaning links that tried to point to other files on the CD that weren't there.
With the Perl DBI interface, you had to set some magic item on the statement or database handle--LongReadLen, maybe--in order to get all of a LONG or LOB. But you could get the whole thing. I mention Perl here, because I used it to copy articles from the Oracle back end of a ColdFusion website to the front end of something built on PHP plus MySql. And before I could even test this, I had to get the data into a different Oracle database, using the standard exp/imp.
I don't doubt what you say, but I do wonder about the experts you encountered.
Is there some edge to Oracle compared to the FOSS stuff that I'm not aware?
One is that there is still a lot of third party (or in house) software out there that doesn't support any of the FOSS databases for its backend. So if you depend on one of those tools then you're not only replacing Oracle, but a bunch of additional software as well. In fact very few people choose Oracle in a vacuum. They 'choose' one of these software platforms and then end up with Oracle. Every time I've worked with Oracle it was because we wanted to/had to use some software that had to use Oracle.
Another point is that there are very few really large PostgreSQL database deployments out there and very few people who have any experience working with huge Postgres databases, while Oracle has been doing that for a long time. If you need 100s of TB in a data warehouse there are hardly any FOSS systems out there with any sort of track record, while for Oracle it is their bread and butter.
That being said, the only people I know still deploying new Oracle systems today are people supporting legacy systems. Even the former pro Oracle people I know are using Postgres these days for almost everything, if only to get away from Oracle's licensing bullshit.
I agree 100% with the "100s of TB" comment. More: If you find a bug in the database, they will fix it ASAP -- sometimes 24 hours or less then will send a patch. (I have seen it more than once in my career, and I am not a super databasey person.) Of course, you pay dearly, but that part is good value for businesses where "the DB is the biz". Businesses that come to mind are telco, utilities (elec, water, gas, etc.), retail/commercial banks, insurance, hospitals, pharma, universities, gov't. In the extreme, they can generate TBs of data per day.
How are they going to send a patch in 24 hours if their test suite takes 20 to 30 hours for a single execution, and any given change causes 100-1000 tests to fail?
Counterpoint. I had a client that used a non-DB oracle product that was a barely functional monstrosity that required the client to keep around a windows XP XM to run a version of IE that could access the console. They spent 3 years trying to upgrade to the new version, even had Oracle professional services come in to help them with the migration, and they couldn't upgrade because the new version of the product was unusable because of bugs and performance, and the old version was a barely functional turd that had to be restarted multiple times a day.
At the end of it all after a multi-year (expensive) engagement Oracle basically just said "That sucks LOL make sure your payment isn't late". So maybe for the DB they are responsive but generally I've found their willingness to help customers similar to a lions willingness to help a wounded gazelle.
People say you can buy commercial support for Postgres - and you can - buy someone who has not seen full enterprise support from the likes of Oracle or even IBM would be amazed.
When your database is down and you’re a major bank and losing millions a minute, Oracle can respond appropriately.
Legacy applications that use mountains of PL/SQL to run business logic. It's possible to refactor this, but these systems are usually the backbone of things like a semiconductor factory, so you don't get a lot of room to play around with alternatives. Paying a billion dollars to keep the current stack running is worth it for a lot of orgs.
I heard some time ago that Intel runs the VMS operating system on much of its production floor. DEC's relational database for this platform was Rdb.
The Rdb database, originally written by DEC, was bought by Oracle in the '90s. It was actually the first commercial database to implement a "cost-based optimizer."
We are using Oracle for something that could fit into SQLite. I am sure we overpay by 100x to 1000x. (To be fair, yes FOSS can be free as in beer, but big corps need/want to pay for support contracts, either directly with the vendor, or indirectly via RedHat, etc.) I agree 100% about PG. It is ridiculously good these days. To be fair, MariaDB is also very good for most use cases in 2022.
I asked the same question at my office. The answer surprised me: We are a big corp who pays Oracle squillions of dollars for all kinds of licenses (DB, Java, hardware, other stuff). They said: If we cut our 20x global DBs from this project, probably Oracle will just increase license fees elsewhere. I was told we probably need total exit from Oracle DBs (whole company, which probably has 1000s of Oracle DBs). That is tough.
Still, it is weird to me that we don't hire 2-5 (10!) ridiculously skilled (and expensive) "old school database consultants" -- you know what I mean: neckbeards (gents), librarian glasses with little chain around neck (ladies), big hair (both!), corduroy pants, jackets with elbow patches, turtlenecks... the full 1990s package. Move them from team to team over next 10 years. Step by step: Replace Oracle with PG or MariaDB. I am sure it would pay for itself 100x.
I'm right there with you on PostgreSQL's impressiveness... I love it and use it everywhere.
However, having done a decent amount of database performance analysis, there is a very good reason I've seen to use Oracle instead of anything else:
Oracle scales more consistently linearly on the biggest variety of workloads compared to any other RDBMS. Give it more cores and it is the RDBMS most likely to give you more performance no matter what you're doing.
I can tell you from my past experiences, organisation who started out with Oracle databases and products have a hard time moving away from them to opensource alternatives. The migration risk and cost of reskilling is very high. There are actual Oracle product experts in organisations who also create resistance towards migration as well as rewriting lot of business logics and procedures is alot of risk. If you start a new company today I'm sure you won't use Oracle database there are better alternatives.
Where I work, our business is mainly based on using our in-house legacy system which uses Oracle database for storage. Migrating away from Oracle involves completely rewriting the legacy system (which I think should have been started many years ago) and that costs money.
As it happens, we're specifically using Oracle Standard Edition in a RAC configuration which is nice and cheap. RAC on standard edition allows you to use up to 4 physical processor sockets without needing to go to Enterprise edition.
One particularly annoying part of Oracle licensing is that if you run it on a virtual machine, they require licensing for every core on the virtual host - it makes no difference how many cores are allocated to the database instance itself.
That would also be really cool, if you could post some comments on MSSQL. I would like to know in general what these paid products really have that we cannot really build with FOSS right now and what kinds of problems/product decisions would make them considerable options when kickstarting new projects. Thanks in advance.
I would recommend focusing on DB2 and Oracle rather than MSSQL if you are trying to learn about that. MSSQL is not particularly expensive in comparison and doesn't really try to compete in the big enterprise league. It's much more similar to FOSS solutions.
I imagine a lot of HNers don't really understand the scope of what Oracle offers in the enterprise setting. This question is like asking: why would anyone still be using AWS in 2022 when OpenStack is available for free?
Yes, PostgreSQL is an impressive piece of software and it certainly deserves all the praise it gets. But the complexity of many mid- to large-sized businesses, particularly those in high-stakes finance and bio/medical tech is impossible to imagine until you've seen it.
Years back, I worked in a mid-size finance company whose computing infrastructure was three identical datacenters scattered across the city. One hot, two standby for DR. All populated with big expensive IBM iron and storage with fast network and fiber channel links between them. All writes were continuously and automatically replicated to all three sites so that even a complete outage at one site meant the workloads could be shifted to another site with virtually no interruption to the business. All of the business logic was written in-house in a variety of languages (but mostly Java) and there were a half-dozen separate teams that existed ONLY to manage the infrastructure. An outage could legitimately cost the company millions of dollars (depending on the scope) in either lost opportunity, customer sales, or regulatory fines.
I was on the Unix Admin team and not counting the toxic management, the scope of our jobs was relatively easy: provision computing resources as LPARs or VMs, manage storage, manage users and permissions, make sure backups worked, automate the shit out of whatever we could, troubleshoot issues, interface with vendors, etc.
The DBAs who sat in the next row over had much harder jobs. They did many of the same things we did, but in the context of Oracle DBs. In addition, they also had to be experts in SQL and schema design, PLUS understand the business decisions underlying the data and structure of the databases they were responsible for. Which sometimes meant arguing with the application developers who didn't grok the platforms their code was running on had finite amounts of RAM, etc.
I don't have any love for Oracle as a company, but they just don't have any competition when it comes to deep integration with highly complex enterprise systems like this.
Vendor lockin. For example I know soutwest airlines uses oracle [clusters, relplicas, etc]. You are going to upgrade them to PostgreSQL? I just don't see that, happening, well, ever.
You should absolutely start with a minimal stack and Postgres is a good choice for that. Everyone likes to pretend that scaling is their problem because it's a sexy problem to have... but really their problem is that the product doesn't exist.
Postgres cannot hold a candle to Oracle or even DB2 when it comes to scale. I've worked at two places did real-time transaction processing on gigunda IBM mainframes. One was Oracle and the other was DB2... This was 15 years ago and the databases were terabytes in size back then... all queryable in milliseconds. Backups, restoration, and schema changes while the system is running is not an issue... And these systems simply did not go down, ever.
FWIW there are several horizontally scaleable relational databases out there (Cockroach, Yugabyte) compatible with pg wire protocol. So you can mostly keep your application queries / driver the same and move to a horizontal solution easier than if you were on Oracle. I don't think Oracle has a horizontally scaling solution. Might be wrong though.
There are differences as these two products have different backgrounds, but based on what I see there is strong movement from Oracle. It will take sometime for application vendors to port their products on open source databases, when this happens the landscape will be different.
Lots of COTS products that depend on Oracle for a backend. Can't just upgrade to Postgres. The vendor may not have the $$ to support multiple databases.
I've used Oracle in a number of projects and I'm inclined to say that it's passable, but if given the choice I would look at alternatives for new projects.
One of the main reasons for this is that setting up local instances (even with Oracle XE) for development or CI processes (e.g. for full end to end tests, that test the actual database layer) is just not as easy as with the alternatives. It might scale up well, but it doesn't scale down that nicely at all.
In addition, I had numerous things breaking when attempting to export and import some data and setup a local database instance for a project that hadn't really been developed with that in mind and up until then had just used a shared database for multiple developers.
That said, Oracle has some nice features to it, such as automatic indexing (which oddly enough doesn't let you manually delete those indices, which is annoying), SQL Tuning Advisor in SQL Developer, some nice performance tracing and reporting functionality, a pretty good procedural language (PL/SQL is up there with PL/pgSQL), good performance in many cases (except I've had the query optimizer pick the wrong plan and have a query take 45 minutes instead of 3 seconds if a hint wasn't present) and a lot of enterprise oriented things I don't use or need, but someone else might.
Tooling wise, I'd say that it's okay. The SQL Developer tooling is okay (maybe apart from their data modeler functionality, which corrupts files and breaks), though personally I like MySQL Workbench as well and dislike pgAdmin somewhat, so my opinions might not be very mainstream. The drivers are available and can be installed without too many issues, there are relatively few surprises there, outside of maybe how widely supported they are (or rather, are not) in certain third party open source tools out there, like various migration utilities.
I suspect that many pick Oracle because that's what has worked for them in the past, some pick it due to the old adage of "Nobody got fired for picking IBM" which can hold true for Oracle in certain environments, others have a mindset of free being bad, or maybe they are perfectly justified in wanting some more support from the vendor.
Frankly, pick whatever fits the task at hand best and is suitable for your own needs: be it PostgreSQL, SQL Server, Oracle, MySQL/MariaDB or something else altogether. If given the choice, I'll personally optimize for technologies that are likely to give me the least amount of headaches, as long as they still fit the project goals.
> Serious question: Can someone explain to me why would someone still be using Oracle in 2022 when we have equally capable or even superior open source alternatives like PostgreSQL, which have none of these shenanigans?
Several years ago I asked this to a company that used Oracle databases in their products.
I pointed out they could save $10 000 for each installation just in licensing, and probably 3 days of intense work to install it (yes, this was my main motivation. I was so good at it I had absolutely no problems with the advanced DBA training, but it still took 1-2 days to set it up the 20th time I did it, and if one missed a single step, like to stop one of the installers between step 2 and 3 to open a terminal and chmod one of the files the installer had just created, you often had to start from scratch.)
The answer was enlightening and went something like this:
"The first thing you don't consider is that the license cost is paid by our customers, and we get a cut. Switching to Postgres would cost us money.
The second thing is that customers see Oracle as a sign of quality. It is easier to sell the product when we say it is built on Oracle "
EDIT: Note, I just re-read the article. This is for the Standard Edition of the database, which basically has no extra features. I've never heard of anyone running Standard Edition except for doing local development.
Yeah, reading that table, the "hack" would be to use "Intel® Xeon® Platinum 92XX" (or similar high throughput intel offering) with an 0.5 multiple.
Does an oracle license pay attention to partial core things like hyperthreading or other speculative execution things? If so, you'd want to turn that off for the intel offerings.
I always wondered, what is the rationale behind pricing certain software as
"per-CPU"? Why not per machine? I'm guessing it's something to do with the size of datacenters and their use of virtualization?
It's pricing based on value. Clearly, someone running a database on a 128-core server is realizing way more value than someone running a 4-core server.
So how do you charge where it's far pricing for both the 4-core server person and the 128-core server person.
Indeed. They are pretty big into cutting edge CPU design. I've seen some pretty cool system architecture coming from them as well. e.g. their cache setups on z mainframes[0]
Can someone say why the Power chips have seemed to not really gain traction outside of IBM? There was a moment a few years back where it seemed that Google might be getting behind the Power9 chips but then we heard very little outside of some press releases. [1]
I remember there was speculation that this was little more than ploy to use as a negotiation tactic with Intel. I'm not sure if that was true or not.
After AMD's 96 core processor, a 24 core chip just doesn't sound all that impressive. The article doesn't address why you wouldn't run Oracle on X86 with more cores.
I'd guess that some software is stuck on Power, so a bigger multi-core chip for those cases is probably cheaper than both porting to x86, or buying a higher tier Oracle license.
If POWER LPARs are the same as Z LPARs then a lot of it comes down to the difference in licensing between hard and soft partitioned VMs. On a typical VM Oracle will charge for the entire cost of the machine, even if the DB is only running on a VM with a fraction of the resources, due to it being considered a soft partition.
At least on Z series mainframes, LPARs are considered hard partitions (handled by PR/SM, not the OS like a KVM situation) and are actually treated as different machines.
I am not sure if this is the case with POWER.
I've never heard of this website and don't know if they are a decent resource, but they seem to cover the issue the way I remember it. Looks like they are offering a license management product that tries to warn Oracle customers about this consideration. I'm sure Oracle slaps people pretty hard over this during their first audits, maybe even hard enough to get a company to shell out for IBM hardware :).
It's a little known fact that IBM creates its SMT-8 cores by taking two of its SMT-4 cores, having one stand on the other's shoulders, and draping a trenchcoat over them so they count as one core for Oracle licensing. The trenchcoat being a de minimis ability to reschedule work from one half to the other. Seriously the per-thread performance you get from 1 thread on an SMT-4 core, 1 thread on a SMT-8 core, and 2 threads on an SMT-8 core are all extremely close together.
I hoped this would explain the anomaly in AMD EPYC 3rd gen
Milan pricing for the 24 core "F" (frequency optimized) parts being cheaper than the 16 core ones, but I still can't see any hint to the reason:
Exploit is a really, really strong word. The way oracle refuses to acknowledge any software processor boundaries other than their own is more exploitative.
It's been several years, but if I remember correctly if you wanted to run an Oracle DB on a 2vcpu VM you couldn't just license 2 cores, you had to license every core on every hypervisor the VM could run on.
It basically means you have to get off oracle or buy oracle hardware. For large enterprises with old hardware running decades worth of business logic captured in stored procedures it's becomes a rock and a hard place situation.
This is a key part of IBMs strategy, since it seems that LPARs on mainframes are treated as hard partitions and do not incur the same "whole machine" cost as VMs. At least that is what IBM themselves say when asked what the target audience is for their Linux only mainframes, which seems to be over 50% just for Oracle.
I only have experience with Z and not as much with POWER systems, so I'm not sure if LPARs on POWER are similar technology or if they are just VMs. But if they are the same that would go a long way in explaining how companies plan to reduce cost by going with IBM despite the increased core multiple licensing cost.
242 comments
[ 3.3 ms ] story [ 244 ms ] threadBTW, BOFH[0] is a great The Register series if you want more of it.
[0]: https://www.theregister.com/offbeat/bofh/
"The BOFH stories were originally posted in 1992 to Usenet..."
https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell
"The Register was founded in London as an email newsletter called Chip Connection. In 1998 The Register became a daily online news source."
https://en.wikipedia.org/wiki/The_Register
I knew that BOFH is old, yet...
> "The BOFH stories were originally posted in 1992 to Usenet..."
I didn't know that it was that old.
Amazing. Thanks for sharing.
My IBM Model M keyboard is from 1985. That's probably the oldest piece of equipment that I actively use.
I've used internet for the first time when the The Register became an online publication.
The article does conclude with this interesting observation:
A: Ah, yes, we are already offering a fix for that bug.
Q: Great! How can I get it?
A: It's in our new upgraded product, Oracle same-as-yesterday(TM). And we are offering it to our trusted existing customers - free of charge.
Q: Free of charge? That's quite generous of you, how unusual.
A: Yes, the customer is king here at Oracle. You just need to sign the license agreement and we can deploy it right away.
We had VMs running a few Oracle databases, nothing much more than 2 cores 16Gb or 4 cores 32Gb, the vast majority (90%+) of our databases were running Sybase, and half the resources were for the app, so something like 5% of those clusters were Oracle dbs.
We were paying Sybase maybe 100k a year for the entire datacenter, and so we expected to pay something between 10k and 100k for Oracle (remember, for 1/20th of the compute and with a developer license because we were not hosting client production).
We asked for a quote to Oracle, they came back a week later with a 520 million dollar bill, more than the revenue of our entire company. It was never paid of course but this shows how absolutely ridiculous their template is for billing. The reasoning is well known now, a 2 core database can run on potentially 6 servers * 32 cores * 2 threads per core = 384 possible cores, so if you have 2 or 3 databases you can potentially get billed a license for 1000 cores (and actually running 6 non-production database = 0 service on their part because if it breaks you just redeploy it, it's faster than opening a support ticket).
Another related but distinct reason is box-ticking purchasing decisions. Decision makers who 1. aren't the end users 2. lack technical knowledge 3. are overconfident and overweigh their own opinion, are likely to decide between products purely based on the number of feature boxes it ticks, regardless of their real-life usability and usefulness. Companies like Oracle know this and cater to it. They don't care if a new feature is useless or poorly implemented as long as it creates a new box that makes the decision makers 0.5% more likely to go with their product.
200bn market cap company ladies & gents
In fairness though - they have a great free tier (if you can live with the arbitrary account terminations)
This is precisely how they are such a giant.
Rule n.1 of sales: you should charge the highest price the customer can bear. By keeping things fuzzy, they can bamboozle you at will, making you pay not what you expect, but what you can.
But annual "support" fees are still 20% (or is it 25% now?) of list price.
Good PL/SQL devs are getting a little rarer these days but its manageable.
On the other hand if your product involves on-site deployment then Oracle is most likely not going to stack up.
I honestly thought this was needed because RAC and some other stuff. Uptime!
Now, a little older and wiser, I know all of these projects would have been fine on Postgres on some hosted provider.
I don't think that ie Postgres has immediate onsite 24/7 support globally, which is much more important for business than pure performance per dollar or similar metrics and they are happy to pay for it. Also trying to find top notch DBAs in Oracle vs Postgres gives, at least here in Switzerland, very different numbers of resources available.
Ie for banks its usually part of their core banking packages and performance-wise not much can replace that (but you need a small army of plsql experts to tame it, although there are plenty of those in the industry).
HPE, Dell, IBM, Oracle itself is building and selling systems designed and optimized for running Oracle databases, for at least a decade now?
I wonder what those banks use for their databases. IMS or DB2 maybe?
Not so say your comment is wrong, there are thousands of banks and average assets of few hundred million. Unlikely they would fork out millions for mainframe setups. Majority of those could be on Oracle as you say.
In these cases generally DBs are migrated to external clusters of their own (like HPE Superdome, Exadata or similarly tailored hardware) and connect via IB or IB like low latency, high performance networking.
AFAIK, the bank I'm talking of is working with "Don't fix what is not broken" motto, and only move what's necessary to modern or external systems.
It just so happens that in the vast majority of use cases, x86 or ARM systems running Linux are good enough for the business purposes. The first few times you run into the situation, you'd be amazed what losses and risks business will tolerate when faced with the costs to mitigate that last 0.1% of profit optimization.
In absolute numbers there are way more commas than the average HN'er retirement portfolio in that last 0.1%. But when it will cost almost the same in the first 3-5 years of migrating to AIX than that number, the IRR payout timeline is way longer than most businesses will tolerate. And most managers are savvy enough to understand the teething pains in the meantime are a career-limiting move.
As much as I am loathe to choose Oracle as a database when solution designing, there is no hesitation when I run into a use cases where nothing but Oracle can address the performance, feature and/or availability requirements, and Oracle RAC comes along for the ride many of those times.
However, anytime I see someone demanding mainframe- or POTS telephony-grade availability outside of an Oracle RAC, and they’re willing to spray the money hose at the problem to get it quickly nearly out of the box instead of underwriting an open source research and development project, I first reach for AIX on POWER System iron to try out the feature fit.
I’m shameless in flirting with whatever tech stack will meet the business and engineering requirements.
In theory the "core multipliers" are supposed to offset this, so a "core multiplier" for POWER or SPARC should be higher - but Oracle also likes to push you towards their own products, so there is a bit of a "bundle discount" particularly on SPARC's core multiplier.
Bahaha, savage :)
Is it really "savage?"
The article was posted long after business hours at IBM. You posted your comment long before business hours at IBM.
It might amaze certain types of people to believe that IBM doesn't have a fleet of PR people sitting around at midnight the week before Christmas to respond to rando online articles.
It's entirely possible that El Reg submitted its query to IBM a week ago and waited for a response that never arrived. But considering the state of internet "journalism" these days, usually they send a Twitter DM and if they don't get a response in the time it takes to finish a Starbucks, they consider it unanswered.
[1] “why create a powerful CPU for a low-end database?”
I'm a backend developer and I regularly kickstart systems (and get to choose which components we are going to use in the stack) and I fail to grasp in what kind of project I'd need to be to even consider "this might need us to bring Oracle to the table". Again, honest to goodness question, looking to learn. Is there some edge to Oracle compared to the FOSS stuff that I'm not aware?
Oracle absolutely solves very hard problems, provides stability and continuity and is 100% the right solution (cost inclusive) for some hard problems.
I'd recommend you recalibrate your judgement of "all thems"
What kinds of hard problems? I think a big part of the discussion here is centered around the fact that aside from legacy software that's exclusively compatible with oracle (in which case you're stuck with it) there isn't yet a compelling reason to use it otherwise vs. eg; postgres w/ a support contract or even something hosted.
FWIW a lot of things people have tried to shoehorn into a traditional RDBMS can be accomplished other ways too.
Probably the vast majority of problems where Oracle is the right solution are problems where Oracle is already in use. That's actually a large market. It's unlikely that new, greenfield solutions have Oracle as the best choice.
But, let's say in 15 years -- people have some hideous brownfield AWS legacy application -- is it worth it to rip and replace an existing block of working infrastructure just because there's some new hawtness?
For new business.
But most big business started long time ago. If it makes business sense to migrate they would. Business sense.
Of course in some it does make sense but it did not. USA tax ?
Non-tech company seeking competent developers to move 100s of thousands of lines of code and sql scripts written by juniors over twenty years from Oracle to Postgres. Must have plenty of Oracle experience but also Postgres experience. Will have to coordinate with DBAs across business units and coerce them to help you in (eventually) axing them.
There is no amount of money that would get me to sign up! And also I wouldn't trust the current team to interview and recruit competent developers!
- It's specialized, so you can charge more for it. And I mean come on, we're saving you millions of dollars. I can charge you a LOT and everyone still wins.
- It's repetitive, so you can train people to do it and then start earning margins as they replicate the process across the organization.
- It's even fulfilling. Yeah, I said it. Would you rather go work on another to-do app in [pick an obscure fruit or animal]-framework for your blog? Count me out of _that_ crap. Any Oracle DB you work on in the wild is going to have an impact on thousands of people--a positive one if you do your job well.
There's an enormous amount of larger businesses for whom the database _is_ the business. (Well, databases plural, they'll inevitably have many.)
I've worked for places where the vendor of the software that sits on top of the DB is either defunct, gone AWOL or too pricey to consider upgrading what ever version of software we were using.
I worked one place where we had to large hadron collide data from Sybase and Oracle together. Live. No batching. The whole thing had to plug into some decades old Delphi crud apps + some financial software somewhere else.
Oracle + dblink made that possible. It even, as I recall, did proper two-phase across the dblink. I merely queried -- yes, I know PG kinda has the same feature nowadays -- across the database boundaries and wrote some pg/Sql to make things work. 10 minutes and $10k (or w/e the Sybase connector cost) later and we had a POC, and later that month, a working system.
Pretty? No. But it worked well, and two disparate software products written in different eras that were never meant to talk to one another now did. And it saves us millions in licencing + bespoke software and expensive consultants.
There are few limits to what you can do with Oracle, and that is its strength. When you have weirdo requirements, you can probably do it with Oracle + some skilled DBAs and be assured it'll still run in 20 years.
As for PG: I love PG, and use it for everything greenfield. But its replication is still a planet-sized joke. There are more competing methods and processes than there are JS frameworks. With Oracle, you've got DBAs who know this stuff inside out, and it works, and it has a million-billion ways of matching the needs of your business. With PG? I don't even know who to call if things are up the creek.
It's just one that has people to call when it breaks.
When you say competitors, do you mean:
1. paid competitors like DB2/MSSQL
2. free competitors like Postgres/MariaDB
3. both
RAC does not indeed.
But the equivalent of an active data guard can be setup in minutes (even less with the right tools) with Postgres. I am sure this is possible with other databases as well.
https://news.ycombinator.com/item?id=18442941
I'm reminded of this anecdote I had with a colleague a while back. He was railing against MS Exchange's rise back in the 90s, and how Novell Netware was better and that he was forced to switch their org to MS Exchange, back then, solely because "His CIO read it was the future in a magazine."
And so it was. Today, Netware's dead.
Could have been a self-fulfilling prophecy, and not something that would have happened without CIOs reading that magazine.
Novell eventually tried to catch up by grafting their proprietary networking features onto Unix but that was too little, too late. The CIOs who started migrating off of NetWare early were the smart ones.
I ported a C++ server and struggled with the only available C++ Compiler for Novell (Watcom). Debugging meant staring at core dumps. Novell bought SUSE too late.
These companies demand a premium over "rolling your own" or "integrating a pile of better at solving a specific problem" products. In some cases the premium is well earned, in others it's just rent-seeking monopolist behavior, depending on how mature the product space is.
It’s confusing because it can apply to landlords who also seek to restrict supply, and people then conflate the former with the term.
Of those companies listed, maybe you can finger Oracle for their shenanigans with Java.
On the continuum of "innovative product solving hard problem" to "Rent seeing monopoly" AWS is still in the "build the mouse trap" phase while oracle's half way to CA.
Oracle licensing on the cloud can be byzantine. In part because their sales people don't seem to all have the same understanding.
https://techcommunity.microsoft.com/t5/data-architecture-blo...
(read the comments!)
Of course, license true-ups in my experience are allowed the latitude of, "Whatever you can get them to agree to". I've heard a few times Oracle sales folks trying to pressure companies into buying licenses for all physical machine cores for the host underneath their VM's in the cloud. Which is, frankly, malarkey and not even supported by their own docs. (Apparently this is how it is licensed on-prem if you own a VMWare cluster or something, but they carve out an exemption specifically for cloud hosting in their docs - but they try anyways)
> With PG? I don't even know who to call if things are up the creek.
The core developers literally sell support...
The startup ran out of money a couple months later..
One 'feature' Oracle has, that is very important to some large companies, is that they offer truly full stack support, from the hardware up to the application layer. If I buy support from some PG developers and they diagnose that the problem is actually with my RAID controller firmware or a bug in my inventory management software, will they still take responsibility for fixing it?
Edit: Another aspect is how long will it take for one of those PG core developers to show up on site? Oracle already has a team of support engineers (either first or third party) in most major cities in the world.
There are plenty of companies offering commercial support contracts. Most of them are also active contributors to Postgres so they do have the ability to create bug fixes and patches.
I remember years ago certain features (materialized views, maybe?) were Oracle-only, but Postgres has more of those now and I'm not sure what's left.
Their job is simply to understand the machine itself rather than the software and make sure they keep it running
2. Support and guarantees. Postgres comes with no exrpress liabilities while Oracle offers some guarantees. Data loss being "their problem" can be a nice clause for business people.
3. Legacy projects. Migrating schemas between engines is usually doable exercise. Migrating application logic can be multi-year project for a decently sized, capable team.
3.1. Cross-project dependencies. Exchanging data via database rather than APIs is more common than one might think. Changing database engine in such circumstances becomes exponentially harder the more projects are involved.
I heard Kevlin Henney call databases "one huge global variable"
It's also very likely implemented by some consultants and I wouldn't be surprised if there's a lot of weird Oracle specific functionality used. Convoluted stored procedures that nobody understands and nobody touches because then it probably breaks.
Oracle also has a very aggressive sales organization. They will defend their accounts. That might be with carrots like discounts. It may also be with sticks, like licensing audits.
We think people using the slightly older version of HTTPS is weird - ERP systems are often so old that the grandkids of whoever started writing it are retiring.
Oracle has things like “pretend to be a version of the database from 20 years ago so this weird load-bearing piece of software doesn’t break.”
The only thing I know of that comes close is Windows itself with its shins and Linus’s absolute refusal to break userspace.
Interestingly, oracle where I work, where we have a lot of oracle, was only 2-3x the cost of our slack license. So either slack was absurdly expensive or oracle isn't actually that expensive, or possibly both. But we only use oracle DB + some support oracle DB widgets, not the whole oracle ecosystem. And for us, the oracle DB and the widgets have been actual facilitators in our enterprise. Need a CDC system? They've got 3!
A commercial database vendor system gave us several free licenses (or cores or something like that) for their platform as part of a deal. Sounds good at first glance. But when you shut down an instance, that returns a license to the free pool. As a result, nobody has incentive to ever do this work. Indeed, if you did free up a license, one of your colleagues might notice and use it on another project. After all, it's free.
The way that databases are commonly used, they become an informal API for communication between systems. One codebase writes an order to the database, another reads it, and another reports on it. Once you this situation, it is difficult to remove. That would require coordination between multiple teams, and it doesn't generate revenue.
For a piece of software like this, it only needs to get in the door once.
An example? A full credit card processor in stored procs. I really mean full, it handled the call outs to financial providers, managed the 2-phase commit, replied to the app, all within a single call (Stripe API is the closest I've seen to this in the 30 years since).
It remains possible to do things that are crazy and powerful, very quickly.
Whether the people here would want to is a different question. But if you are in a large corp and Oracle is available it is easy to do crazy things.
Once these things are done, Oracle is going nowhere. They are now in your system for the life of your product.
1. Organized in some regular repo with some tooling to deploy/sync 2. Some way of tracking versions _in a DB_ and some magic set of queries that can deploy from said DB.
That method of building fossilizes quicker than quickcrete.
Once you have the Oracle infrastructure for Financials, PeopleSoft, etc, the question is does it make sense to stand up services around the Oracle portion. The cost of the people to run Postgres or MS SQL server may be more than the marginal add of Oracle.
Awesome. I have probably dozens of posts over the years about why one would choose Oracle, so I won't rehash it all right here, but I'll link some relevant ones. Briefly though:
> in 2022 when we have equally capable or even superior open source alternatives
This isn't really true. Postgres is a truly excellent RDBMS, but most people compare it at a rather superficial level, because many use only very superficial features. If you need to insert, select, update, and delete, you have a lot of compelling options. (This can easily veer off in another direction, but I astounds me how many people shun the database and chose to reimplement innate features in procedural code outside of the database.) For example: Oracle has an extremely richly featured, powerful, and stable data warehousing feature set that has no open source analog.
A lot boils down to build vs buy. Some places build because it's exciting. Some don't even know that the thing being built has existed for three decades. This applies equally to open source. It's entirely possible that a materialized view will obviate your whole external caching infrastructure.
https://news.ycombinator.com/item?id=23068341
https://news.ycombinator.com/item?id=32246208
If you have a few large monolithic applications that share multiple schemas (so no single-owner), and you then need to do classic OLAP, OLTP and cubing, you're essentially stuck with database solutions from the same era. Same goes for record-oriented software and mainframes or low level rtos software that requires real mode. The requirements never stand on their own (which is pretty much what you wrote anyway ;-)
If a BI solution can do gRPC to a few specific services that contain the datasources for the dimensions you need, then nearly all OLAP-native features are irrelevant. It also means that the dynamic resource usage means that your overall cost in terms of energy and money are significantly lower.
The big 'if' in all of those is going to be 'does the organisation have the skills and the willpower', and often the answer is no. Because hiring some MSP to do your BI, data management and have some single vendor do your ERP, EHRM, ESB on top of some RDBMS "sounds" good and means it's their responsibility, and when a user then sends them a support ticket about how crappy their UX is and how much the workflow sucks, they will get ignored and somewhere in some expensive place, old grey men shake hands on yet another successful quarter ;-)
Opinion: Why would you say there is no open source analog to the Oracle DWH setup? CitusDB has been able to replicate the mix and match of OLAP and OLTP for quite a while now. In my time as an architect in MSFT we were competing (and successfully too) with CitusDB and Postgres against bespoke complex Exadata setups already a few years ago, and CitusDB just keeps getting better as they integrate more and more options for working with columnar data.
Oracle just straight up ignores all the goodness that has come out of modern operating systems and still tries to peddle Exadata setups with custom hardware nodes and whatnot when a large swathe of those problems can be solved horizontally instead of vertically.
If your business is a thin layer around a finely tuned Oracle setup then ofc it becomes pretty stupid to suggest moving off that and into Postgres in any kind of less-than-five-years project. I would say though that for new projects it is most likely cheaper to either hire postgres experts to replace your oracle experts or just let your Oracle gurus forget all the vendor specific tuning you don't really focus that much on in Postgres than it is to pay for Oracle.
My argument never has been that it's purely a feature play; in fact, I think RDS made Oracle far more compelling, because I got to offload the majority of the day-to-day. Now, with citus on azure, yeah, it's pretty compelling on the operating cost side.
> If your business is a thin layer around a finely tuned Oracle setup then ofc it becomes pretty stupid to suggest moving off that
Right. It's really and end-to-end thing. Oracle serves pretty much every significant business problem. It has a giant API and huge function library that I can use to implement pretty much whatever I want. Then, I can turn it over to the auditors, who know it and understand its operations, so compliance is relatively easy when it comes to things like HIPAA/PCI/FERC or whatever.
It's not just about tech. It make a lot of sense for a lot of businesses.
Now that I'm not as heavy in regulatory environments and more in science, I think I'd be very happy with the offering. (In fact, I am actively using postrges, and not actively using oracle right now.) I might miss some of the in-built reporting functionality that Oracle has, but I'd have to have a look at the very latest offerings in that area from citus.
https://docs.oracle.com/database/121/DWHSG/sqlmodel.htm#DWHS...
CTE expression is an optimization fence in postgres, which is not the case in oracle.
2. oracle does not need vacuum, unlike postgres
3. postgres has problems with many concurrent connections, thats why you need workarounds like pgbouncer. Oracle doesnt need that.
And same picture with almost any other feature - it is sort of "works" in postgres - but with crutches/workarounds, while in Oracle - stuff just works out of the box.
You dont need to search and install some obscure opensource extension to get the thing you want working, like you do in postgres world. and then keep updating that extension with every new version, etc
generally not true since PG12
At the bank I worked before 2019 at I was on a advanced analytic team, we had this amazing teradata database and then there were these insanely fast (yet older) IBM DB2 databases and then there was a few big oracle databases.
We did amazing things with teradata + DB2 and then a leader who was tired of multiple databases asked us to vote, we chose teradata so we went with oracle and the migration was so bad I left.
In contrast, most Oracle DBAs/Engineers publish the fact that they have only used this specific product during their whole career. They seem to be rather proud of the fact, actually.
- I agree that, by default, the on-demand pricing model is pure consumption, and folks can and do mess up sometimes.
- I had a habit of refunding folks when they asked, and if they made obvious mistakes, even though it took me an average of 3-4 hours to process each refund.
- BigQuery has cost controls to prevent runaway costs, sounds like you must check it out ASAP
- BigQuery also has a DDL option to require users to include a partition filter predicate in queries
- BigQuery also has flat-rate pricing, on which the vast majority of folks above SMB on. There are no runaway costs with this one.
I think generally BigQuery is a great example of an extreme serverless consumption-model. You have thousands of cores at your fingertips, and, well, if you do something that overuses, you are allowed, but you do pay for it.
However, I agree its a really cool tool, I have not worked on the ETL side of things, but we use BigQuery in almost all of the projects I have been on, my teams usually needs to figure out the right query to determine key KPIs our clients usually ask for and the SQL is really helpful.
Interesting. Why?
I was thinking more along the lines of them not having servers in my country, so I have to send my data abroad if I want to use the service at all.
I've done this from time to time, and it's usually a question of the database clients are much easier to scale than the database. What can the clients do to reduce database i/o and cpu, because I can add more clients easily, but turning a database into a cluster is relatively more difficult, so database machines have to scale up instead.
Otoh, the limits of machine scaling are quite high these days. You can get a single socket epyc with 64 cores and 3TB of ram and tons of lanes of nvme.
Leading us perfectly back to the topic of this post!
Unfortunately Oracle has become far to aggressive in lawsuit for a lot folks like me to ever be comfortable building anything with their products. Same for SalesForce, I just killed a project that we wasted $200k on but we'll save a lot more killing it rather than becoming dependent on SF next year. Oracle gets you over barrel, then charges you through the nose when they know you're in too deep to move. Their products are great, but the companies themselves are too dangerous to work with.
In the end I learned that Oracle can't even output it's own data properly, even with the help of experts. I also got to learn what installing Oracle software was a really like (it was brutal).
So, no, I would not recommend Oracle to anyone, ever.
1. I worked with developers trying to implement a UI using Oracle's app-builder of the time (Oracle Forms? I don't remember). The devs spent an entire summer, with Oracle support, just trying to get the system set up and configured to build "Hello World." They gave up and we abandoned the project.
2. I needed to install an Oracle product on my computer. I had an Oracle provided CD. The install was non-obvious: multiple install files with multiple options and ways to get it wrong. On the CD was a set of help files, with an app to view them. The app did not default to showing the help files: you had to select which base file to start with. The choice was not obvious. There were broken links in the help system -- meaning links that tried to point to other files on the CD that weren't there.
In short: Oracle -- not even once.
I don't doubt what you say, but I do wonder about the experts you encountered.
One is that there is still a lot of third party (or in house) software out there that doesn't support any of the FOSS databases for its backend. So if you depend on one of those tools then you're not only replacing Oracle, but a bunch of additional software as well. In fact very few people choose Oracle in a vacuum. They 'choose' one of these software platforms and then end up with Oracle. Every time I've worked with Oracle it was because we wanted to/had to use some software that had to use Oracle.
Another point is that there are very few really large PostgreSQL database deployments out there and very few people who have any experience working with huge Postgres databases, while Oracle has been doing that for a long time. If you need 100s of TB in a data warehouse there are hardly any FOSS systems out there with any sort of track record, while for Oracle it is their bread and butter.
That being said, the only people I know still deploying new Oracle systems today are people supporting legacy systems. Even the former pro Oracle people I know are using Postgres these days for almost everything, if only to get away from Oracle's licensing bullshit.
On the other hand, there's this legendary description of what working at Oracle is like: https://news.ycombinator.com/item?id=18442941
At the end of it all after a multi-year (expensive) engagement Oracle basically just said "That sucks LOL make sure your payment isn't late". So maybe for the DB they are responsive but generally I've found their willingness to help customers similar to a lions willingness to help a wounded gazelle.
When your database is down and you’re a major bank and losing millions a minute, Oracle can respond appropriately.
The Rdb database, originally written by DEC, was bought by Oracle in the '90s. It was actually the first commercial database to implement a "cost-based optimizer."
https://en.wikipedia.org/wiki/Oracle_Rdb
It was purchased by Oracle, is still maintained, and is likely on Intel's VMS systems.
https://www.oracle.com/database/technologies/related/rdb.htm...
(I also have an account on a system that runs it.)
I asked the same question at my office. The answer surprised me: We are a big corp who pays Oracle squillions of dollars for all kinds of licenses (DB, Java, hardware, other stuff). They said: If we cut our 20x global DBs from this project, probably Oracle will just increase license fees elsewhere. I was told we probably need total exit from Oracle DBs (whole company, which probably has 1000s of Oracle DBs). That is tough.
Still, it is weird to me that we don't hire 2-5 (10!) ridiculously skilled (and expensive) "old school database consultants" -- you know what I mean: neckbeards (gents), librarian glasses with little chain around neck (ladies), big hair (both!), corduroy pants, jackets with elbow patches, turtlenecks... the full 1990s package. Move them from team to team over next 10 years. Step by step: Replace Oracle with PG or MariaDB. I am sure it would pay for itself 100x.
However, having done a decent amount of database performance analysis, there is a very good reason I've seen to use Oracle instead of anything else:
Oracle scales more consistently linearly on the biggest variety of workloads compared to any other RDBMS. Give it more cores and it is the RDBMS most likely to give you more performance no matter what you're doing.
In fact, Oracle and MS SQL specifically disallow posting benchmark comparisons publicly
One particularly annoying part of Oracle licensing is that if you run it on a virtual machine, they require licensing for every core on the virtual host - it makes no difference how many cores are allocated to the database instance itself.
Yes, PostgreSQL is an impressive piece of software and it certainly deserves all the praise it gets. But the complexity of many mid- to large-sized businesses, particularly those in high-stakes finance and bio/medical tech is impossible to imagine until you've seen it.
Years back, I worked in a mid-size finance company whose computing infrastructure was three identical datacenters scattered across the city. One hot, two standby for DR. All populated with big expensive IBM iron and storage with fast network and fiber channel links between them. All writes were continuously and automatically replicated to all three sites so that even a complete outage at one site meant the workloads could be shifted to another site with virtually no interruption to the business. All of the business logic was written in-house in a variety of languages (but mostly Java) and there were a half-dozen separate teams that existed ONLY to manage the infrastructure. An outage could legitimately cost the company millions of dollars (depending on the scope) in either lost opportunity, customer sales, or regulatory fines.
I was on the Unix Admin team and not counting the toxic management, the scope of our jobs was relatively easy: provision computing resources as LPARs or VMs, manage storage, manage users and permissions, make sure backups worked, automate the shit out of whatever we could, troubleshoot issues, interface with vendors, etc.
The DBAs who sat in the next row over had much harder jobs. They did many of the same things we did, but in the context of Oracle DBs. In addition, they also had to be experts in SQL and schema design, PLUS understand the business decisions underlying the data and structure of the databases they were responsible for. Which sometimes meant arguing with the application developers who didn't grok the platforms their code was running on had finite amounts of RAM, etc.
I don't have any love for Oracle as a company, but they just don't have any competition when it comes to deep integration with highly complex enterprise systems like this.
You should absolutely start with a minimal stack and Postgres is a good choice for that. Everyone likes to pretend that scaling is their problem because it's a sexy problem to have... but really their problem is that the product doesn't exist.
Postgres cannot hold a candle to Oracle or even DB2 when it comes to scale. I've worked at two places did real-time transaction processing on gigunda IBM mainframes. One was Oracle and the other was DB2... This was 15 years ago and the databases were terabytes in size back then... all queryable in milliseconds. Backups, restoration, and schema changes while the system is running is not an issue... And these systems simply did not go down, ever.
If a software product uses those integrations it may be difficult to migrate.
Bear in mind that DB code is often not unit tested or integration tested outside of manual tests.
This makes moving off of Oracle a huge tech debt burden.
===
Ask me how I know this
It's been attempted a few times over the years, but gets canceled once management realizes the actual cost and difficulty.
Nouveau DB projects and tech companies undoubtedly lean towards FOSS options.
The IBM solution is aimed at those maintaining an existing stack.
Not just COTS...lots of in house systems
One of the main reasons for this is that setting up local instances (even with Oracle XE) for development or CI processes (e.g. for full end to end tests, that test the actual database layer) is just not as easy as with the alternatives. It might scale up well, but it doesn't scale down that nicely at all.
In addition, I had numerous things breaking when attempting to export and import some data and setup a local database instance for a project that hadn't really been developed with that in mind and up until then had just used a shared database for multiple developers.
That said, Oracle has some nice features to it, such as automatic indexing (which oddly enough doesn't let you manually delete those indices, which is annoying), SQL Tuning Advisor in SQL Developer, some nice performance tracing and reporting functionality, a pretty good procedural language (PL/SQL is up there with PL/pgSQL), good performance in many cases (except I've had the query optimizer pick the wrong plan and have a query take 45 minutes instead of 3 seconds if a hint wasn't present) and a lot of enterprise oriented things I don't use or need, but someone else might.
Tooling wise, I'd say that it's okay. The SQL Developer tooling is okay (maybe apart from their data modeler functionality, which corrupts files and breaks), though personally I like MySQL Workbench as well and dislike pgAdmin somewhat, so my opinions might not be very mainstream. The drivers are available and can be installed without too many issues, there are relatively few surprises there, outside of maybe how widely supported they are (or rather, are not) in certain third party open source tools out there, like various migration utilities.
I suspect that many pick Oracle because that's what has worked for them in the past, some pick it due to the old adage of "Nobody got fired for picking IBM" which can hold true for Oracle in certain environments, others have a mindset of free being bad, or maybe they are perfectly justified in wanting some more support from the vendor.
Frankly, pick whatever fits the task at hand best and is suitable for your own needs: be it PostgreSQL, SQL Server, Oracle, MySQL/MariaDB or something else altogether. If given the choice, I'll personally optimize for technologies that are likely to give me the least amount of headaches, as long as they still fit the project goals.
That said, comments like this were interesting to behold: https://news.ycombinator.com/item?id=18442941
For new projects, the choices are wide open.
Several years ago I asked this to a company that used Oracle databases in their products.
I pointed out they could save $10 000 for each installation just in licensing, and probably 3 days of intense work to install it (yes, this was my main motivation. I was so good at it I had absolutely no problems with the advanced DBA training, but it still took 1-2 days to set it up the 20th time I did it, and if one missed a single step, like to stop one of the installers between step 2 and 3 to open a terminal and chmod one of the files the installer had just created, you often had to start from scratch.)
The answer was enlightening and went something like this:
"The first thing you don't consider is that the license cost is paid by our customers, and we get a cut. Switching to Postgres would cost us money.
The second thing is that customers see Oracle as a sign of quality. It is easier to sell the product when we say it is built on Oracle "
POWER has a 1x core multiple today (meaning, you have to license every core).
https://www.oracle.com/assets/processor-core-factor-table-07...
EDIT: Note, I just re-read the article. This is for the Standard Edition of the database, which basically has no extra features. I've never heard of anyone running Standard Edition except for doing local development.
Does an oracle license pay attention to partial core things like hyperthreading or other speculative execution things? If so, you'd want to turn that off for the intel offerings.
And run one socket to maximize memory bandwidth.
If someone has a 128-core AMD EPYC, they probably have more money that can be extracted than a person with a 16-core EPYC.
I'm not sure it should be characterized that way.
It's pricing based on value. Clearly, someone running a database on a 128-core server is realizing way more value than someone running a 4-core server.
So how do you charge where it's far pricing for both the 4-core server person and the 128-core server person.
Oh Register, never change.
[0] https://www.youtube.com/watch?v=z6u_oNIXFuU&t=577s
I remember there was speculation that this was little more than ploy to use as a negotiation tactic with Intel. I'm not sure if that was true or not.
[1] https://www.computerworld.com/article/3052811/ibms-power-chi...
At least on Z series mainframes, LPARs are considered hard partitions (handled by PR/SM, not the OS like a KVM situation) and are actually treated as different machines.
I am not sure if this is the case with POWER.
I've never heard of this website and don't know if they are a decent resource, but they seem to cover the issue the way I remember it. Looks like they are offering a license management product that tries to warn Oracle customers about this consideration. I'm sure Oracle slaps people pretty hard over this during their first audits, maybe even hard enough to get a company to shell out for IBM hardware :).
https://bluemedora.com/the-hard-and-the-soft-of-oracle-licen...
It's been several years, but if I remember correctly if you wanted to run an Oracle DB on a 2vcpu VM you couldn't just license 2 cores, you had to license every core on every hypervisor the VM could run on.
It basically means you have to get off oracle or buy oracle hardware. For large enterprises with old hardware running decades worth of business logic captured in stored procedures it's becomes a rock and a hard place situation.
I only have experience with Z and not as much with POWER systems, so I'm not sure if LPARs on POWER are similar technology or if they are just VMs. But if they are the same that would go a long way in explaining how companies plan to reduce cost by going with IBM despite the increased core multiple licensing cost.