When I worked at a megacorp as a dev, I had near zero say in such purchase decisions. I had to work with what I was given. Thankfully I work for a much smaller shop now. Better pay and much better decision autonomy.
That is only partially true. Oracle has a wide portfolio of a bunch of products and the "wine & dine the execs" is the sales cycle for software like ERP Oracle E-Business Suite and Oracle Health (Cerner). E.g. it's the hospital CFO & CIO that are the true "customers" of Oracle Health and not the frontline doctors and nurses that use it.
However, for the Oracle RDBMS database ... it was often the developers that chose it over competitors such as IBM DB2, Sybase, Informix, MS SQL Server.
In the late 1980s and early 1990s, a lot of us devs did a "bake off" with various databases and Oracle often won on technical merit. E.g. Oracle had true row-level locking but MS SQL Server before v6.5 was page-level locking. And the open source alternatives of MySQL and PostgreSQL at that early timeframe were not mature enough to compete with advanced Oracle features such as Parallel Query Execution and Recovery from a Standby database.
E.g. the C Language programmer Shel Kaphan at Amazon chose Oracle in 1994: https://www.linkedin.com/posts/jpcharles_in-1994-amazons-fir...
(that anecdote cited this deep link: https://www.youtube.com/watch?v=u3qIWN-ZIPk&t=1h11m56s)
It took Amazon 25 years to finally migrate off of all Oracle databases: https://www.google.com/search?q=oracle+shuts+off+last+oracle...
So young devs today who aren't aware of history will wonder why Amazon ever got locked into Oracle in the first place?!? It was because in 1994, Oracle db was a very reasonable technical choice for devs to make.
While the internal implementation details differ from Oracle, the end result seems quite similar in practice.
As a sysadmin/dba I get to handle the nasty side of Oracle: the bugs, the patches that fail, the redundant tools, the wordy documentation that always feels like a never-ending advert.
Our small company was building enterprises things for large clients. And one of them wanted Oracle on Windows server. They also wanted a failover setup. How hard could that be?
Now I hate Oracle. I hate Oracle consultants. I despise the ignorance.
My favourite bit was Oracle uninstall procedure. I had like 4 pages printed just for this case.
Oracle bad. Postgres good.
Automated tests of T-SQL stored procedures are also possible. There are couple of ways you could do that, but in our case we just write “unit” tests in C# which call the procedures. This integrates nicely into Visual Studio’s Test Explorer, is debuggable etc. You can even step through a C# test, and then just “step into” T-SQL being called from there!
There are valid reasons for not putting business logic into stored procedures, but “not being a proper language” is probably not one of them, at least in the case of T-SQL. Then again, there are also reasons for using stored procedures. Everything is a tradeoff…
So it's likely that, for a specific task, the oracle solution is crap, but oracle has crap for everything so the oracle sales droid can sell a "one throat to choke, one check to write" policy to a company that likely has technology problems but produces a "not technology" product.
Amazon's moving into this space and their crap is even stickier than oracle's...