Oracle offers everything. Databases, web frameworks, programming languages, CRMs, cloud management tools, auto scaling clusters, identity management, BI, document search, email servers, colocation, mainframes, calendar sync. You name it, they've got it. Oracle has products ready to go to run an entire country if it needs to.
Sure, Postgres beats OracleDB, but Postgres doesn't integrate as well with Oracle Fusion and you need to migrate the code yourself. They're like SAP: they're big enough that you can make a career just out of configuring their software packages and make good money while doing so.
It's expensive and certainly not the best, but it's reasonably stable and has a huge company backing it. Oracle won't disappear any time soon and they're not as likely as Google or Microsoft to shut down their services within a few years notice.
In some countries, Oracle is also very good at doing what Google and Microsoft are doing to students. The Brazilian programmers I've spoken to specifically learned OracleDB when they were taught relational databases. They learned to program in Java, and I'm sure Oracle also sponsored other parts of the professional tooling they got to use for free. Microsoft, on the other hand, didn't seem to generous towards their educational facility (no free MS tooling for their schools like they offer over here). If all you know is Photoshop/Windows/Maya/OracleDB/iOS, you're going to look for jobs where you can use Photoshop/Windows/Maya/OracleDB/iOS, and employers looking for cheap juniors will need to offer Photoshop/Windows/Maya/OracleDB/iOS to make the best use of them.
Are we sure? I'm by no means a DBA, but DBA at our company (who is freaking smart btw) said if money wasn't an issue, he would actually go with OracleDB.
An example, Oracle has global unique index when a table is partitioned, Postgres doesn't.
Again, I haven't worked with OracleDB at all, and my postgres knowledge is limited, but assuming without having experience with both systems isn't fair to either DBs IMO.
Every large database vendor forbids public disclosure of benchmark results these days - ie Snowflake, you name it. Privately it's a different story obviously.
I work with engineers and technical managers with 25+ years of experience, building and maintaining serious business software 'you could run a country with' - people here build react web apps or do scientific research, or work for a SaaS provider - completely different view than building highly complex, regulated, mission critical software that supposed to run for decades and be supported at this level.
I think it's an arrogant and naive mistake to think nobody reading hacker news has ever built anything complex, regulated, mission critical, or intended to last.
A more useful line of conversation might be discussing the vastly different requirements and environments (both physical and bureaucratic) that span our industry. Right now I'm a one man dev team slinging multiple products as fast as I can, trying to find revenue as the runway burns up. It would be silly to think everyone is in my same position with my same tradeoffs and I don't expect that to be particularly controversial.
If you have some good insight about when Oracle products are particularly well suited to the task I think many folks would love to read and discuss it. If you just want to act like you're the only one taking your job seriously then I suggest you just save your keystrokes and everybody's time.
The Oracle database is an amazing piece of software. The problem with it is as open source and SQL Server started eroding its share, Oracle pivoted to owning vertical line of business software.
My employer probably spends more money on databases for our learning management system than we do for one of our main customer facing apps with thousands of concurrent users. It’s literally a tally of training courses.
Postgres is a better choice for 99% of the companies out there. But there are cases where you need ability to massively scale AND control your database cluster perfectly.
Postgres won't even let your force an execution plan and ignores hints (yes, there is an extension for that) so your optimized query can at some point just 10x in execution time and increase load in production when the plan changes.
In Oracle, I am told you can prioritize certain queries at certain time of day - it's crazy what it can do. Yes, it's slow and expensive. If you have money to throw at the problem, it's fast and it solves your problem, whatever the scale. Their Exadata cluster, for example, is wicked fast storage layer pre-filtering the data it sends to the database.
Of course, I despise their business practices - especially the abuse of customers via audits. As a database, it absolutely has its place regardless of lobbying, corruption, and whatever else they are doing.
> Postgres won't even let your force an execution plan and ignores hints
Finally, an actual technical argument. I agree that PostgreSQL's absolute insistence on trusting the query optimiser to Do The Right Thing is weird and annoying (despite being sound general strategy). It even seems to contradict its own general spirit of being on the whole extremely customisable -- you can make your own data types, operators, indexing data structures, complete scripting language plugins... but not, ya know, a way to 100% guarantee that this here query will use this here execution plan.
Beats at what? Not mission critical multi decade setups that can be easily repeated by hiring someone from postgres consultancy. Oracle handles every use case you throw at it: maybe not optimally, but that is not what you care about at that level anyway. They suck but what are the actual alternatives: not postgres or supabase for most orgs of significant size.
As much as I hate Oracle, there are huge advantages to Java. Java is strongly typed, free, and runs damn near anywhere. It's pretty much the go-to language when people think about OOP and for good reason. It has some excellent open source IDE support and it's widely used in the industry. With the current OpenJDK setup, it's also free of Oracle's licensing issues. It runs fast and can support most algorithms you'll probably ever study, without the manual memory management troubles of something like C++.
I was taught C# in uni for very similar reasons except the entire uni ran on Windows and the Microsoft platform, which made doing assignments on Linux rather inconvenient. With the status of dotnet core, I'd say Java finally has a good competitor when it comes to teaching OOP languages.
Java has been a staple of university courses since before Oracle bought Sun. I guess I am getting old now, if the kids all want to program in Python and Javascript for 4 years...
Java was taught far before that: we got taught the first public beta version in the 90s in uni. Thought it was nonsense compared to c, prolog, lisp and Haskell.
Because Oracle comes to any country/industry with trucks of money to corrupt officials and lobby their adoption.
And after a few years you find yourself in a situation when you already paid for Oracle so much, integrated it so deeply, so switching to any alternative is a massive pain and in most cases it’s safer and easier to keep paying Oracle.
I believe this is how they grew and how they remain big. While smaller companies aim for managers, Oracle targets CTOs and CEOs, takes them out for expensive dinners and promises them the world. Then, they legacy handcuffed them forever. And virtually no one chooses to invest crazy amounts of money on migrating or even starting a new codebase when your company lifeblood has been poured into the Faustian Oracle machinery.
The ones targeted by Oracle salespeople don't. And when they do, it's too late. And most just hope things "will work out". I was third party witness to one of these transformations and I correctly predicted the chaos, uncertainty and sense of powerlessness that it would cause
It's legacy lock in. You can't just switch stuff. it's incredibly hard to move logic out of store procedures from on DB to another. Its the same reason why the US government runs on Cobol. People don't think about the strategic implication of the tech they choose and how it may come back to limit them in the future.
Most Oracle "shops" i know have used it for decades. When they started using it, there weren't many options, so Oracle was what was used.
COBOL is in the same category. When invented, it was the absolute easiest programming language to learn and use, so of course it gained popularity.
It then turned out to be rather good at what it did, along with running on hardware that "never fails", so most places didn't even think about replacing it until sometime in the 90s.
Also keep in mind that the reason companies are migrating away from COBOL is not due to the language as much as due to young people not taking an interest in COBOL and Mainframes, making it hard to recruit new talent.
Even then, a migration away from a typical mainframe is a huge task. In most cases you're talking 50-60 years of "legacy" (still running, still working, still updated) code, and replacing a system that has evolved for half a century is not an easy undertaking, at least not if you plan on getting it 100% right the first time.
> young people not taking an interest in COBOL and Mainframes
It is more like young people not wanting to:
- throw their careers out of the window by pigeonholing themselves into zombieware tech
- experience high levels of stress trying to debug code older than their parents, writing code that can't be unit tested and pushing said code to production
I'm willing to bet that if you start a career in COBOL programming today, you will live a long and happy life as a COBOL programmer until your retirement age, earning more than your peers who chose NodeJS, Go, Rust, Kotlin, or whatever is modern today or tomorrow.
The only language that comes even remotely close is Java, in terms of job guarantee.
I doubt it's more stressful. Debuggers absolutely do exist, as do modern desktop editors with step by step debugging, but you will have to learn at least a little bit about memory management, SQL, and other "nasty relics".
It appears to be a part of the skillset that is no longer taught. I've worked in the embedded industry for a decade, and we usually had little more than trace lines over a serial cable to debug our code, and yet we somehow made it work.
I've long since realized that being a skilled programmer has very little to do with what language(s) you code in, and more about your understanding of the problem space. Yes, you can be a star in Advent of Code if you know every nook and cranny of your chosen (esoteric) programming language, but often people that understands the business side of things will fare much better.
And yes, I've also been young once, and I've programmed in just about every programming language that has been "modern" or "old" in the past 30-40 years (I've even written software in APL), and I've been good at it. I also absolutely despised the thought of programming in COBOL, but in the end, programming is about telling the computer what to do, and the what is the important part, not the how.
> due to young people not taking an interest in COBOL and Mainframes
Having only fleeting professional experience with COBOL during a summer my view of it is that it is a mix of dataanalyst job and programming. Where the programming is horrible and the report making is ok though archaic. As long as you modify processes already available it is not so bad, but the developer experience was horrible.
With all that said I actually liked ideas in COBOL but it is an extremely niche language that does not serve you at all in the real world.
The "real world" of airline reservations, the world's financial infrastructure and basically anything involving hardcore real data processing runs on COBOL.
But yeah, if you're looking to code up a progressive web app or next blockbuster MMORPG, I wouldn't recommend COBOL.
The top (in the world) 2 airline reservation system Amadeus have ported everything to Kubernetes for years now. In fact they were among the top contributors to the project a few years back.
It's all a matter of age and maturity. Nobody starting an airline, or financial company, or "hardcore data processing" today even bothers considering a mainframe or COBOL.
Fair point! From a personal perspective it was about interfacing with the real world like parsing data, bitbanging or writing drivers. I actually have no problem with doing BI web apps with COBOL.
> In most cases you're talking 50-60 years of "legacy" (still running, still working, still updated) code, and replacing a system that has evolved for half a century is not an easy undertaking, at least not if you plan on getting it 100% right the first time.
This seems like an application area in desperate need of applied A.I.: Analyze a codebase and replicate it (for the first few iterations at least) in the new target language.
Isn't there research on this ? Or am I full of balonie ?
It's pretty common for business contracts to just end up stuck on mainframes or scattered across various systems from vendors like Oracle (the paper trails are often thrown away long time ago).
And let's be honest, a lot of folks in IT aren't exactly top performers and don't seem to care all that much. It's really the developers you find on forums like this who are genuinely passionate. You're not likely to bump into the people actually buying those big Oracle or IBM systems around here though :)
I know they get a lot of hate but I personally used Oracle’s cloud and it seemed like a decent piece of infrastructure with really solid engineering team behind it. They had their share of problems (and their first line of support is really really bad and not well suited to handle real issues) but not really any different from any other similar products.
I made a similar experience. The database just stopped working one day, triggered by a normal restart without any updates or patches. Fixed the configuration, tested it, restarted multiple times, everything works. After a week it was not working again, without me being able to fix it except doing a fresh reinstall on a clean VM.
Luckily more and more customers switched to Postgres and I no longer have to deal with it.
