Why anyone would use Oracle for anything other than supporting legacy systems is beyond me.
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...
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.
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.
Are Oracle cloud offerings actually doing well? What evidence is there of this?
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.
When you have thousands of engineers, "complexity" is very subjective.
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.
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.
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.
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).
Is it smart to have all of your web app code running in the database, making it impossible to run without the Oracle Database?
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.
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.
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.
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.
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.
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.
You get a RESTful interface to PG. All you need to add is a static page w/ some JS, for which you can use react-admin or similar.
Presto: web apps written in PG.
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.
1. see "Infamous Dropbox Comment": https://news.ycombinator.com/item?id=9224
Sample PostgREST apps: http://postgrest.org/en/v6.0/ecosystem.html
React-admin: https://marmelab.com/react-admin/ and https://github.com/marmelab/react-admin
React.js: https://reactjs.org/
Combinations:
- https://github.com/tsingson/ra-postgrest-client - https://github.com/raphiniert-com/ra-data-postgrest - https://reactjsexample.com/a-react-web-application-to-query-... - https://github.com/tomberek/aor-postgrest-client - https://github.com/priyank-purohit/PostGUI - https://awesomeopensource.com/project/priyank-purohit/PostGU... - https://www.reddit.com/r/learnpython/comments/bzrr1c/how_to_...
More links:
- https://github.com/topics/postgrest - https://duckduckgo.com/?q=%22postgrest%22+%22react%22&t=ffab... - https://duckduckgo.com/?q=%22postgrest%22+%22react-admin%22&... - https://react-admin.com/docs/en/ecosystem.html
I'm sure you can find more!
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.
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.
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...
- RAC and distributed transactions across a database cluster
- Integration with APIs
- 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
Also Oracle was the first RDMS to support stored procedures in Java.
So source isn't available yet you are able to judge the code quality, interesting.
No, disassembling bytecode isn't a reflection of the quality of the original source code.
I didn't say code quality, I said usage of obscure and internal hacks from the JVM and JDK
Also Oracle drivers also run in other JVMs, so which JVM are they abusing then?
As for why speaking about the drivers, I have had my share of driver issues during the last couple of decades, when going enterprise scale.
Who in their right mind would do that ? It's a nightmare on so many levels....
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.
You have this on postgresql.
> RAC and distributed transactions across a database cluster
Needed only in telcos where galera would be enough
I have used distributed transactions at life sciences.
That is not the same as using Oracle.
Anyone trying others to adopt their products is a vendor, regardless if they are commercial or open source.
Also Linux is just a kernel, naturally it needs a vendor like RedHat or Canonical to provide an actual product.
Postgres is a RDMS already out of the box.
E.g., in most Apache projects originally donated from a corporation, that corporation's employees usually still constitute a majority of the developers.
The corporation(s), in such cases, aren't sponsoring the project in any strict technical/legal sense. Rather, the project is steering and constraining the corporation(s) in their development efforts on their forks/extensions of the project codebase, determining through the project's core maintainership's decisions, what will be accepted/upstreamed from those corporate forks/extensions into the open core, vs. what will have to remain in those forks.
See: Redis vs. Redis Labs; CouchDB vs. Cloudant; Apache BEAM vs. Google Cloud Dataflow; etc.
You should reassess your critics before posting, I think. The evolution of postgresql is faster and faster.
Pushing for those plugins as alternative just shows how little one knows about the feature level of Oracle capabilities.
I have managed teams of database administrators for roughly 10 years. And I know that using those arcane features or depending too much on those capabilities has cost millions to my company.
Avoid implementing everything in a database.
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.
ClickHouse is a read-only analytics database and overlaps with Oracle in only those areas, otherwise Oracle blows it out of the water.
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.
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.
Oracle DB has no problems with TB-sized datasets, and if you have that kind of data you're probably not worried about Oracle-sized licenses.
> That leaves only niches for oracle.
Why do people keep beating this dead horse? Oracle DB is backing a non-trivial % of global GDP in a large number of Fortune 500's. It's not niche, it's just not a tool you use for hosting WordPress, Magento, and RoR apps.
We're a two-man startup selling analytics of blockchain data. We have a several-terabyte data set and basically no hosting budget. I don't think we're all that unusual. Dataset size does not imply organizational size/budget.