Hacker News Reader

Comment by fb03 | Hacker News Reader

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?

View on HN

> honest to goodness question, looking to learn.

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

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.

Just a little addendum, rds is SE only and not EE, so almost no big business can use it regardless unless its for some small r&d etc.

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?

Like what?

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.

Picking one of your previous comments at random where you use the examples of pattern matching and analytic functions... yea postgresql does that too.

Why did you leave out the thing it doesn't have? That's what we're talking about, after all.

https://docs.oracle.com/database/121/DWHSG/sqlmodel.htm#DWHS...

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.

I think they mentioned SQL modelling being part of the core software.

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?

> CTE is optimization fence in postgres, which is not the case in oracle

It has not been an optimization fence for three years now. I was one of the co-authors of the patch which fixed that.

> CTE expression is an optimization fence in postgres, which is not the case in oracle.

generally not true since PG12

Oracle people tend to be heavy oracle people too.

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.

Couldn't this also be said about, say, Postgres specialists?

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.

> even though it took me an average of 3-4 hours to process each refund

Interesting. Why?

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.

they certainly do not move data to another country without your explicit direction.

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.

fair point!

> 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.

96 cores and 6TB per socket with Genoa!

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!

On the move, but I'll respond shortly

> 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.

Disclaimer: this happened over twenty years ago.

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.

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.

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.

> it's worse than most of its competitors on durability, performance, cost, etc.

When you say competitors, do you mean:

1. paid competitors like DB2/MSSQL

2. free competitors like Postgres/MariaDB

3. both

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.

> 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.

It can be setup, but will it work?

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.

You can get commercial support for PostgreSQL that's pretty good.

From this classic HN comment it sounds like working on the Oracle codebase is an exercise in clusterfuckery:

https://news.ycombinator.com/item?id=18442941

Sounds like they spend 80% of their CPU cycles checking flags...

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."

And so it was. Today, Netware's dead.

> 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.

Could be. That would mean it was good judgement to read the magazine that the other CIOs were also reading.

I'm not sure sprinting towards a self-fulfilling prophecy should count as good judgment. It seems like there's a fallacy in there.

It makes sense if the self-fulfilling prophecy is outside your control.

Yeah, it's called "marketing" :D

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.

Novell was no fun.

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.

Marketing to decision makers is true and tested method to make inferior product popular tho

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 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)

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.

All your example are pretty much "we already have some old ancient shit that works only with Oracle", not actual features anyone might miss...

> With PG? I don't even know who to call if things are up the creek.

The core developers literally sell support...

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..

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.

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.

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.

> If you find a bug in the database, they will fix it ASAP -- sometimes 24 hours or less then will send a patch

On the other hand, there's this legendary description of what working at Oracle is like: https://news.ycombinator.com/item?id=18442941

what does that gotta do with what he said?

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?

The bugs I saw were in query compilation and execution. They probably only run a portion of the test pack.

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.

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.

"Hundreds of thousands of dollars" is cheap compared to "staff", and staff time costs direct dollars.

Oracle and AWS offer the same offerings at different points in the product maturity lifecycle.

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"

> 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.

What kinds of hard problems?

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?

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!

Or you just haven't undergone an Oracle audit yet. From what I saw, their business model is entirely predatory.

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.

AFAIK, Oracle also offers large discount/kickbacks for the chief, who knows to negotiate.

> Exchanging data via database rather than APIs is more common than one might think.

I heard Kevlin Henney call databases "one huge global variable"

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 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.

Thank you for the reply!

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

Oracle has a much more effective sales team than PostgreSQL. A few basketball tickets to the right managers makes all the difference.

I see. I guess you are right. The endless Samsara of people with a MBA and their churn to keep plates spinning.

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.

This answer contains more truth in it than any technical answer ever will.

We can all be so blind sometimes to the 8th layer of the OSI model.

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.

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.

> 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 "

> I regularly kickstart systems

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.

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.

Often the consulting was done... by Oracle itself!

I've seen Oracle 1000 times for ERP.

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.

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.

It'd be probably a fraction of the costs to hire competent developers to implement the missing features in PostgreSQL.

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.

Yes, I would sign up! That sounds like a fun job which pays well. I love that kind of jobs.

"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.

There is basically 0% chance that they are doing something so unique that it is impossible to be done or workarounded with other databases.

I agree, but each migration has a small risk of introducing bugs. Sometimes subtle bugs. Who is going to be blamed?

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.

There hasn't been reliable benchmarks to that effect.

In fact, Oracle and MS SQL specifically disallow posting benchmark comparisons publicly

It’s not for new development but ERPs which require it. Oracle also makes a bunch of ERP platforms.

You may expand to DB2, IMS etc. The question as usual IT is not everything. It is everything to us. But not to business.

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 ?

If core of your business is not IT you can not be fired for selecting Oracle.

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."

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 large part of the workforce makes a living maintaining and extending systems, not building them. In fact, I call that success.

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.

For my company it's the massive cost and difficulty of rewriting a major portion of the codebase of a 20-something year old successful product.

It's been attempted a few times over the years, but gets canceled once management realizes the actual cost and difficulty.

Oracle offers some integrations that are not found in other DBMS products.

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 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.

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.

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.

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.

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.

The "rip and replace" costs far exceed maintaining an existing Oracle stack for many businesses.

Nouveau DB projects and tech companies undoubtedly lean towards FOSS options.

The IBM solution is aimed at those maintaining an existing stack.

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.

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.

Not just COTS...lots of in house systems

Because when something doesn’t work you can pick up the phone and call someone at Oracle. Who would you call when you have problems with Postgres?

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.

Main reason would be they have a lot of legacy code written for Oracle.

For new projects, the choices are wide open.

Do you have the same question about SQL Server, or is it just Oracle you're asking about?

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.

No CIO ever got fired for buying… Oracle?

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.

That said, comments like this were interesting to behold: https://news.ycombinator.com/item?id=18442941

Reply on news.ycombinator.com