For one, it does things that the competition is not capable of or just inferior -- and despite the bias on this site, the major consumers of RDBMSes are not price sensitive scrappy startups.
There is no comparison between the HA offerings in Oracle and something like Postgres, which are comparatively toys. Replication doesn't equate to HA and the "nobody got fired for buying xxx.." actually has some justification. Why would I risk my reputation on a flimsy solution just to save a few bucks in a large corporation?
I would argue that using postgres today sets you up better for HA tomorrow, as both yugabyte and cockroachdb are built with postgresql compatability in mind. I would also argue your reputation as a competent CTO / Architect / whatever is more at risk by choosing Oracle in 2020.
> I would argue that using postgres today sets you up better for HA tomorrow
The point is, if I have the money I can get enterprise grade HA today. Yugabyte and cockroach are promising but they’re small unproven organizations and as history has shown they’re likely to get bought out and then who knows.
Larry Ellison is an asshole, Oracle the company itself makes me want to vomit but they are a pretty known quantity.
> CTO / Architect / whatever is more at risk by choosing Oracle in 2020.
This trope started reaching fever pitch during the first wave of OSS commercialization hype/fervor in 98. It wasn’t true then and I see no evidence it is any more true today.
(I am the CTO of Yugabyte) Your points are all completely valid. Just wanted to add my 2 cents.
With YugabyteDB specifically, we are more than just PostgreSQL wire-compatible, we "reuse" the upper half of PostgreSQL to support almost all PG features (examples: stored procedures, triggers, partial functions, etc). So the aim is to build something that has "almost all PG features" while being able to "run cloud-native - with HA, scale and geo-distribution" - our hope is that this allows YugabyteDB to really become a viable option instead of PostgreSQL when apps are being built for the cloud. Here is a blog post on the benefits we realized reusing PostgreSQL: https://blog.yugabyte.com/why-we-built-yugabytedb-by-reusing...
> This trope started reaching fever pitch during the first wave of OSS commercialization hype/fervor in 98. It wasn’t true then and I see no evidence it is any more true today.
It is not. And I know of several major banks leaving oracle "en masse" because of licensing nightmare. The major decision makers are now endangered by their choice of oracle as a database to consider. Oracle in a new project is now a firm NO.
Regarding HA, active/passive and failover is enough for 99% of the use cases.
For the rest you'd need citus or patroni, but it's totally manageable.
I'd be quite dismissive of an architect who suggests oracle if there are no extreme availability requirements.
I'd also prefer a galera or an innodb cluster for active/active architectures.
Let's face it: oracle database is dying an its niche is shrinking.
> oracle database is dying an its niche is shrinking.
This is true, but misleadingly not the whole truth.
On prem RDBMS is dying and its niche shrinking (at least in this part of the cycle)... having said that, Oracle cloud offerings are doing very well.
Amazon made a herculean effort, and made some headlines when they migrated most of the business off Oracle last year. That's wonderful, for Amazon. Most of Oracle's enterprise customers are not Amazon.
> I'd also prefer a galera or an innodb cluster
The thing is.. Oracle sells so much more than just an DB engine, and people are buying. Oracle RDBMS is not an inferior product to open source competitors, in most ways superior, and yet, it is really just a proverbial loss leader.
> Oracle RDBMS is not an inferior product to open source competitors, in most ways superior
It is also in a lots of extremely critical ways inferior. The huge complexity, the huge footprint, the humongous prices are enough to justify staying far away from it.
This is the point that's getting missed on this site. Oracle can charge a fortune for their products precisely because they can still deliver things that other RDMS's can't and they are still offer the highest performing DB if you're willing to pay for it. Most business don't require this level of performance, but many do.
Yes, if you're a startup with an MVP that recommends good deals on imported wine, sure you can, and really should, use a simpler open source RDBMS. But, if you're a large established company with billions in revenue and need a DB that delivers as close to perfect reliability as possible, then spending a small fortune on Oracle licensing and all the hassle that comes with it, is a pretty minor thing relative to the bigger picture. A critical failure even once in a blue moon will cost an order of magnitude more than your licensing fees.
There's a lot of obituary writing for Oracle, but think the real story is that Oracle is going to go from the dominant RDBMS provider in business world, to a niche player occupying the high end of the market. It might be where they want to end up, but it's not a terrible place to be, either.
I think the major feature from proprietary RDBMSes that you rarely see in OSS RDBMSes is workload management.
The ability to set CPU, RAM, disk and network quotas on queries or users is extremely useful and powerful. That capability by itself is pretty close to non-negotiable for any large line-of-business system.
I know there is something of an OSS RDBMS renaissance happening at the moment, but I haven't heard of any of them offering this, except for Greenplum ... which used to be proprietary.
Disclosure: I work for VMware, which sponsors Greenplum, so it makes sense for my awareness to be biased.
I have not been an Oracle fan in the past, especially because of their complicated (and expensive) licensing, but late last year we moved to their hosted autonomous database. The on demand pricing model makes it quite economical, and the performance is amazing.
However, the killer feature for me is that it has application Express (or APEX) included, which is a complete web application development framework, as well as Oracle restful data services (ORDS). With built-in application development and deployment, it is the only complete, full-stack data management platform I am aware of (enterprise level).
YRMV, but it has been incredible for us, both to support our data science initiatives, and for rapidly deploying applications. I couldn't imagine going back to anything else.
My last job was 100% based on ApEx. Which I do not bring up on my LinkedIn profile.
I refer to ApEx as "Access, for the web, for Oracle". For what it's good at, it's pretty good.
The biggest plus in my view is that it rewards careful schema design. Point it at a properly-normalised schema and you can get 80% of a useful CRUD interface for 20% of the effort.
But all things being equal I'll be happy to never use it again. It's hard to test, hard to version control, hard to safely extend (you usually wind up with buckets of PL/SQL below the surface).
That is somewhat of a concern, but less so now that they support web services. So, you would still need a basic oracle DB set up in order to run APEX, but you could just use OracleXE, which is a quite capable free version, and then connect to whatever you want.
Also, you see this argument a lot - "what if I want to switch databases"? I've seen more than my share of overly-complicated and highly non-performant code bases, "just in case we want to change our database at some point" (see the ORM messes out there.) Its a problem in theory, and in my experience, not in practice. Never in 25 years of IT work have I switched databases, so it's often a classic case of "prevention worse than the disease".
One case where this use to be an issue was for software vendors that used to sell applications requiring a database, and they had to be ready to work with whatever the customer had. In our day of cloud based apps, this is increasingly becoming less of an issue.
"What if I want to switch" is a valid question if your business is at the mercy of a single vendor with a history of abusive business practices towards its customers.
While I may have a selection bias, I have seen quite a lot of companies migrating their applications, successfully. Most for exactly this reason. And many, perhaps even more, that would very much like to migrate if it was less disruptive.
Yep - agreed. It's "pick your poison". No matter what tech stack you select, migration away from it is a may be a consideration. (Whether it is a JavaScript framework, PHP to python, C++ to Go, or one DB engine to another.)
If being able to easily switch technology stacks is important to your business success, then you need to optimize for that. That's not the case for me.
> YRMV, but it has been incredible for us, both to support our data science initiatives, and for rapidly deploying applications. I couldn't imagine going back to anything else.
Out of curiosity, are your data scientists actually happy with this? All of ours are using Python notebooks with Spark or RDS, and I think there'd be an armed revolt if we asked them to migrate to anything else.
So far, yes. APEX in this case is used for data visualization and dashboards, mostly using Plotly.js.
And, the oracle database is the data store for clean/structured data. They use python notebooks and all the other python based goodies for their work - the DB is just where they get their data. (And, sometimes it makes sense to do data processing with the DB). We could end up using Spark at some point - we're not precluded from that.
> However, the killer feature for me is that it has application Express (or APEX) included, which is a complete web application development framework, as well as Oracle restful data services (ORDS). With built-in application development and deployment, it is the only complete, full-stack data management platform I am aware of (enterprise level).
Yeah those architectures were nice in the 90s. We don't do that anymore, for a whole lot of reasons. Being locked in with such a nefarious vendor is such a big risk.
Yep, you could do that and I'm sure it will work well, just like you don't need dropbox because "you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem."1
Once we signed up with Oracle Autonomous DB, we immediately could start developing and deploying web apps and web services all within the platform, without installing or integrating any other tools, and I'm not aware of another enterprise level platform where that's possible "out of the box". So, re: the original comment, that's why we chose Oracle for a reason other than supporting legacy systems. It helps us go fast, performance is great, and the on-demand licensing gets us all that without breaking the bank. There are definitely other ways to achieve the same thing (as you suggest), but I'd rather not spend my time doing any of that, just like I'd rather not roll my own dropbox, trivial though it may be.
Can you point me to a good resource on this? I work 100% in the data layer right now, but the idea of being able to create an easy frontend (assuming I learn react) would be wonderful.
Yeah, there's not one solution. There are many. Many are open source. PostgREST is amazing. The rest is up to you, but there's tons of tools out there.
Oracle and SAP have products that touch niche areas of businesses. Oil company with complex shipping and receiving looking for accounting software? Global metal foundry who needs to track raw materials to finished goods and forecast everything? SAP and Oracle can sell your VP overly complex products for almost anything.
For the DB, corporate executives types feel much more comfortable choosing Oracle or IBM. It usually bites them in the ass down the road due to licensing or support costs.
This is certainly all true, and with Oracle, absolutely everything is negotiable. Nobody pays list. It still isn't cheap. If you are going the Oracle route, you might even consider hiring a consultant to do the buying, because relationships and knowing the Oracle way can make a huge difference.
Also, Oracle Database itself is more than just an RDBMS and has an enormous amount of features that have no analogs in Postgres or any other non-commercial system. Take a look Oracle's data warehousing components, like advanced analytical SQL, pattern matching, and the especially cool modeling: https://docs.oracle.com/database/121/DWHSG/sqlmodel.htm#DWHS...
> - A much better experience in Java and .NET drivers, including SQL custom data types.
I didn't have any better experience with Oracle drivers in Java. Most of the driver is a soup of hacks exploiting obscure features of both the VM and standard library (both the vm and jdk are "Oracle owned" so I guess I was expecting that), also the source code is not available, so debugging it's a hellish experience.
On the other hand the Postgres JDBC Driver is the most well written and documented driver that I ever saw in Java
Sure it works, and is well tested and mature, and so are most of the jdbc drivers, never had any problem with any jdbc driver, aside of digging to code to understand some not documented behaviours. I don't see why put the Java driver as a benefit point of Oracle, most of the developers problems and issues don't occur at the JDBC level. It might be true for .NET but I'm really supicious if the Oracle support is that better over others
I didn't say code quality, I said usage of obscure and internal hacks from the JVM and JDK
> - A much better experience in Java and .NET drivers, including SQL custom data types.
So I'll admit, I haven't used the Oracle Provider for .NET since 2017.
Oracle.DataAccess is not the friendliest library to work with and I've seen some weird issues with pooling in past use. Devart has a good provider, but somewhat limited in free features (still a better general experience than Oracle's provider, but you don't get all the custom bits unless you pay).
PostgreSQL on the other hand has a very nice ADO Provider in NpgSql. It can look a bit daunting with all the config options offered but overall I'd still say it's a better API experience than Oracle.DataAccess.
> - A much better developer experience for stored procedures, with proper packaging, compilation to native code, graphical debugger.
Oh I do miss Oracle Packages so so much. Yeah, they could be a bit annoying to deal with from a 'gobs of code in one file' standpoint, but it's -so- nice to just have PKG_CUSTOMER, PKG_LOCATION instead of having to scroll through all the individual stored procedures, having to guess whether people named things in a way you could find them...
Edit: For a long time, you could have added
- Arguments about how to store a boolean value
But thankfully Oracle finally took care of that in 12.
dbeaver and plugin_debugger. For distributed transactions, it all depends on why you need them in the first place but there are multiple solutions in postgres to handle them.
Postgres isn't an RDBMS "vendor." Third-party service providers are who you have relationships with. It's like Linux vs. Windows. You don't have a relationship with "Linux"; you have a relationship with RedHat or Canonical, who take responsibility for integration, support, and maintenance of their upstreams (kernel, core libraries, userland packages, etc.)
Plugin_debugger is availlable on postgresql.org's repo.
And supported by our postgresql support provider.
You can of course use pgadmin, the official tool, with this plugin.
You should reassess your critics before posting, I think. The evolution of postgresql is faster and faster.
I STRONGLY dislike Oracle the company, and the Oracle DB is quite complex, however Oracle RAC (HA) beats the pants off anything else out there as far as performant, reliable HA. Oracle DB also has been the leader performance wise for complex queries and large datasets. All of that is very important in my niche (enterprise grade eCommerce).
> Oracle DB also has been the leader performance wise for complex queries and large datasets
SQL server has a column store type of storage, and major innovations like 'froid'. Oracle is not such a strong leader there.
Also, on a whole lot of workloads clickhouse is much superior.
Yes, and? If you're choosing a tool to deploy for that workload, why would you deploy Oracle instead of ClickHouse? The same question goes for any other analogous workload. Why use something that's second-best at 100 different jobs (Oracle), when you could just choose the best-in-class tool for the exact job you're doing each time?
Especially since, in the particular use-case we're talking about here (data warehousing), the whole paradigm and all the tooling is built around the expectation of ETL pipelines copying+transforming+"cubing" data around from OLTP (or data-lake) systems to OLAP systems. "Everything being part of one solution from one vendor" doesn't make one whit of difference in that case, since the whole architecture is expected to be built around having a one-way pipeline of mutually-opaque interoperating systems, so any two pipeline stages that can manage to speak to one-another at all can't really be any "more" well-integrated than that.
> Especially since, in the particular use-case we're talking about here (data warehousing)
I didn't read any context of data warehousing except for the ClickHouse comment.
When comparing CH to Oracle, there's at best a 10% overlap. Within that overlap, CH is pretty amazing in what it can offer. However, for the remaining 90% Oracle kicks the shit out of CH.
CH does not have to worry about being an OLTP database and everything that entails (transactions, MVCC etc.) That means CH gets to take a LOT of shortcuts to offer what it does.
I thought that by large datasets you meant TB of data that we see in analytics. And in this area clickhouse is growing and coming to the big companies I work for, one way or another.
postgresql handles the OLTP decently enough.
That leaves only niches for oracle.
It's mostly used because the people who hold the purse strings in large organisations don't have a clue about databases, but the salesmen for Oracle wear fancy suits, take them out for expensive dinners and treat them like chums so they get the deal.