Amazon’s consumer business has turned off its Oracle data warehouse
bloomberg.com
bloomberg.com
Now I see things differently -- the non-traditional databases are just better at scaling horizontally, eventual consistency, and running in cloud environments than the traditional databases. They are easier to set up and use. Some of them now have pretty good relational features and schemas.
During the past decade the Oracles of the world have continued to think dismissively of new non-traditional databases, as I did at first. The non-traditional databases got better and better while Oracle kept doing a lot of the same stuff. Oracle just didn't take the competition seriously, and that's fair enough because the competition didn't deserve to be taken seriously at first -- but now it does, and it's becoming a threat to Oracle's business.
It's obvious that Amazon would want to use their own database products -- but the impressive thing is that those products, which are not very old, are already good enough to replace Oracle for a lot of use cases at very high scale.
Honestly, IMO the biggest issue holding noSQL databases back is lack of good documentation/support a lot of the time. Technically, though, they're going to become the standard for most use cases soon.
Whereas implementing a Key-Value Store is orders of magnitude simpler. There is plenty of room for innovation, of course - but you don’t need 1,000 people to build-on some new replication scheme or distributed backend.
If you take a simple NoSQL system then tack on things like object scheme support, JSON blob value indexes, node graph support, etc you’ll end up with an RDBMS analogue.
So the barrier-to-entry to building a NoSQL system is much lower than a RDBMS - and for many companies they might decide to build their own rather than extend an existing system - leading to more completion but not necessarily a better product.
CockroachDB is the newest from-scratch SQL engine that I am aware of: https://www.cockroachlabs.com/
They re-use the RocksDB K/V store maintained by Facebook (in C++) as the storage layer, and their own code is written in Go, so I suspect that their development work is probably a lot less time-expensive than the teams working on older SQL databases.
Based on license revenue it's actually Oracle and MS SQL server by miles. They are currently #1 and #3 on DB-Engines.com. (https://db-engines.com/en/ranking) MySQL is #2. PostgreSQL is #4, though it's pretty far back from the first three.
I mean PostgreSQL is open source, and required no license fee. I'm not sure that license revenue is a good comparison metric.
It's popular on HN to focus on OSS products, but there's a very large proprietary RDBMS market measured both in terms of revenue as well as users. That's how Oracle and MS got to be the behemoths they are today.
This doesn't require something relational, just something centralized. And not even that; consider Spanner.
So you basically want full consistency (vs eventual consistency) in a distributed environment. You can set up you noSQL that way. I don't see how relational DB's are "better" than noSQL in consistency.
There are hundreds maybe thousands of NoSQL databases ranging from Redis to MongoDB to Cassandra to InfluxDB to Druid. They pretty much have nothing in common other than storing data. Many of them support SQL directly, others via Spark and almost all have a SQL equivalent.
To whit, de-normalised tables for the sake of "efficiency".
It's pretty difficult to under normalise a two column table -- which is what K/V is.
Yes, like traditional car companies not taking EV's too seriously, or Intel not taking mobile/ARM too seriously, etc. It seems the older and more established a company is, the thicker their forward-thinking blinders are. "We're king, no one can EVER touch us."
Relational databases solved the problem they had, of requiring much developer effort to evolve for new application needs, and re-organization of the datastore for changing performance needs. Basically, everything is a table, and you can combine/separate tables, from whatever form it currently is, to whatever form you currently need. This is also helpful for reporting (as opposed to operational applications).
But relational databases, like dynamic languages, pay a performance price for their flexibility.
Of course, every other innovation has since been added, and there's Oracle's licensing too. So it's much more complex than the base technology of relational algebra.
I'm not sure this is true, you can look at the new features in 8i, 9i, 10g, 11g, 12c and see that Oracle is adding a lot of features, and some of them are very impressive. The problem is most people don't need most of them and if you want any of them you have to pay for all of them.
And the "non-traditional" databases had a pretty low bar. MongoDB just had to stay up for more than 5 minutes and not lose your data. Do they even do that yet?
What are you implying? Do you have any source for that? Some of the top tech companies out there use non-traditional databases, including MongoDB. They won't if the nodes crash every 5 minutes and/or there is data loss.
There are other non-traditional databases that are much better than MongoDB.
Amazon had a big outage in recent times that their own post-mortem linked to trying to move off Oracle to Aurora.
Interestingly it was posted here to HN and repeatedly and immediately flagged off the page - it appears that some HN readers are very keen on suppressing anything that paints Oracle in a good light. It makes you wonder what other stories might be going missing that would alter people's impressions of this company.
Andy Pavlo, database professor at CMU, has debunked it and gave details on the journalist's dishonesty.
Also, anything is better than oracle. If not for technical reasons, price wise it makes a lot of sense.
Your last sentence appears to be typical of the problem I'm describing.
I've seen such outages after an Oracle version upgrade so it's all but major.
For your information I've been managing critical databases for more than a decade so I know that it might look unusual to you, but it's quite clear to anyone barely knowledgeable about database management that the article really overblown the issue. It was also mocked by Amazon's CTO.
So please, manage databases for a few years. Then I might hear your opinion and maybe consider it.
The main reason technically-capable companies like Amazon or Netflix are moving away Oracle has nothing to do with horizontal scaling. It's the licensing costs. Oracle is just too expensive for them, and even if you are not Amazon yourself, RDS (or any other Cloud RDBMS) would be much cheaper for you.
Oracle sued my company a few years back for license compliance issues - I vowed never to run their stuff again and rip it out wherever I find it.
He has?
https://www.cnbc.com/2018/10/22/aws-ceo-jassy-follows-apple-...
I imagine at the scale of Amazon replacing some of the core data stores with all their existing data is a quite complex task. Just think about the amount of data you need to migrate and keep in sync during the migration and all the third party tools using such data. So while it takes long, I don't think Amazon is particularly slow doing it.
From Wikipedia: "Note that there was no v1 of Oracle Database, as Larry Ellison, "knew no one would want to buy version 1."
https://en.m.wikipedia.org/wiki/Oracle_Database#Releases_and...
You can pick up any of their product and find that MYSQL, MS-SQL etc are supported but 2001/03 release because of "incompatibility issues". If that is not enough Oracle's support is clueless about what are these "incompatibility issues". And given the precarious security environment we are in, everyone needs a DB which has been patched sufficiently and allows newer features like TLS 3.0 etc, you are left with no choice but to go for the only supported DB is Oracle DB. I have sat in many meetings where the CIO/CTO have seen this as an arm twisting tactic by Oracle.
I am no market expert but if Oracle keeps going down this path they will cease to exist in next 10-15 years.
The one I miss most is resource constraints on queries. It's nice to be able to guarantee that some queries will get more resources than others.
On the other hand, Oracle's SQL dialect is (or was, I stopped using it about 5 years ago) full of frustrating backwardness. No boolean type, so you get a mix of CHAR(1)s or INTs, depending on the prevailing DBA's opinion. And there's no serial or autoincrementing type, so for every table you wind up copying and pasting the same code over and over (create index, create sequence, insert trigger, update trigger).
The most head-scratching part is that you can find apologists for these flaws.
We have a lot of applications running on Oracle databases at my company, and therefore a lot of Oracle DBAs.
Now they prefer MariaDB or PostgreSQL for most new projects because Oracle has become too aggressive with their business practices, pricing and audits.
But now the DBAs must learn PostgreSQL and that requires some non trivial effort on their part to become as proficient as they were with Oracle.
I knew some engineers that worked on a centralized data engineering team that served 100+ software teams, and they managed several thousand scheduled queries. I felt so bad for the guy that had pager duty that first night. He said he got a sev-2 every 12 minutes on average for 24 hours straight.
I certainly hope Amazon has fixed their data warehouse issues since then.
I'd bet that their Oracle Data Warehouse being referred to here isn't just about the Oracle RDBMS database technology itself, they are talking about a specific COTS Oracle Data Warehouse model that you can buy prebuilt and works as a destination for all other Oracle ERP etc. subsytems.
I say this knowing it first hand coming from a company trapped in that particular Oracle stack. It's expensive, limiting and very locked in, and has a huge footprint and requires specialists to run (as do many ERPs).
I see actually a mad scramble by the big tech vendors (Microsoft, SAP and others) trying to push their ERP solutions as cloud enablement has opened up a window of opportunity to shift and escape some of the pains of the old ways (while creating an entirely new set of problems).
I'd be more interested if Amazon sees this same opening and is trying to enter the ERP game itself by building something in house that they turn around and offer as a service via AWS. They certainly have the scale to look pull off such a thing, and they already own all the enabling technologies to build an ERP system, data warehouse and rest of the stack.
That's my pet theory at least!
https://www.nasdaq.com/symbol/orcl/after-hours-chart
The “lawnmower” keeps on mowing: https://news.ycombinator.com/item?id=18323166
According to db-engines.com, Oracle has declined 9% since July 2016. Amazon Redshift and Google BigQuery have grown over 50% in the same period, while Snowflake and PrestoDB (although each are 10x smaller than Redshift and BigQuery) have grown over 60%.
This is happening because enterprises are shifting to the cloud. When they go to the cloud they are shifting -away- from on-prem warehouses like Oracle, Teradata, and Vertica. Enterprises choose Amazon or Google depending on which cloud platform they adopt.
Companies launched after 2010 were born in the cloud (and thus never used Oracle since Oracle does not have a cloud) and are more likely to choose Snowflake due to ease-of-use (even as Snowflake is more expensive than Redshift).
What does this mean?
Consider that we are still in the early phases of cloud adoption. 32% of enterprises are in the cloud, rising to 52% by 2022. At the same time, over half of enterprises said they will use more than one cloud (hybrid cloud) within the next 10 years.
Amazon Redshift is the warehouse of choice for Enterprises on AWS. Snowflake is eating up the mid and SMB markets. prestoDB solves awesome problems for interactive and exploratory analysis for all. BigQuery is used by GCP customers.
These trends indicate that Oracle will struggle to grow revenues and margins, as they are relegated to serve the (still large but shrinking) portion of the market that chooses on-prem, and pursue aggressive rent-seeking of an aging install base (the Java mess is an unrelated but telling example of this strategy).
To reverse this trend, Oracle must find a way to serve cloud customers. That probably means acquisitions.
When Oracle entered the cloud they started making fun of Amazon, “If their cloud and database offerings are so great, how come they use us to do the actual heavy lifting? That’s because our stuff is rock solid and theirs isn’t”
This pissed off Bezos, the sky broke and a voice foretold, NO MORE ORACLE!
How many folks still actually use Oracle? And how many are trying to get rid of them?
With cloud availability and many of the features of high end DBs commoditized, and the new strain of apps being cloud / SaaS, Oracle's available market has dried up.
Personally, I don’t expect to see Oracle die in my lifetime. They will keep cannibalizing other companies to stay alive, probably forever.