IBM creates 24-core Power chip so customers can exploit Oracle database license
theregister.com
theregister.com
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.
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.
BTW, BOFH[0] is a great The Register series if you want more of it.
"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."
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.
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.
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?
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.
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.
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 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.
https://docs.oracle.com/database/121/DWHSG/sqlmodel.htm#DWHS...
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.
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
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.
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!
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 ;-)
- 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.
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.
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.
> With PG? I don't even know who to call if things are up the creek.
The core developers literally sell support...
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.
The startup ran out of money a couple months later..
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.
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)
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.
It's just one that has people to call when it breaks.
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.
When you say competitors, do you mean:
1. paid competitors like DB2/MSSQL
2. free competitors like Postgres/MariaDB
3. both
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.
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.
On the other hand, there's this legendary description of what working at Oracle is like: https://news.ycombinator.com/item?id=18442941
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?
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!
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"
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.
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.
Their job is simply to understand the machine itself rather than the software and make sure they keep it running
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.
That method of building fossilizes quicker than quickcrete.
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.
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.
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 "
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.
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.
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.
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
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 ?
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.)
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.
It's been attempted a few times over the years, but gets canceled once management realizes the actual cost and difficulty.
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
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.
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.
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
When your database is down and you’re a major bank and losing millions a minute, Oracle can respond appropriately.
For new projects, the choices are wide open.
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
model | cores | price |
73F3 | 16 | $3521 |
74F3 | 24 | $2900 | <- cheapest
75F3 | 32 | $4860 |
model | cores | price |
9174F | 16 | $3850 |
9274F | 24 | $3060 | <- cheapest
9374F | 32 | $4850 |
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.
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 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...
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...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.
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...
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.
Oh Register, never change.
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).
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.
HPE, Dell, IBM, Oracle itself is building and selling systems designed and optimized for running Oracle databases, for at least a decade now?
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.