Blog Post

Amazon declares war on Oracle (again) with new Aurora database

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

Once again Amazon Web Services is taking on Oracle, the kingpin of relational databases, with Aurora, a relational database it said is as capable as “proprietary database engines at 1/10 the cost,” according to AWS SVP Andy Jassy.

This is a new battle in an older and broader war. Amazon’s RedShift took the battle for data warehousing to the incumbents Oracle, Teradata and others, a few years back.

Aurora, which will join MySQL, SQL Server, PostgreSQL, and yes Oracle on the company’s Relational Database Service (RDS) lineup,  is compatible with MySQL, [company]Amazon[/company] said.  It goes into preview today.

Amazon is right that customers, even big [company]Oracle[/company] customers who hesitate to dump tried-and-true database technology are sick of Oracle’s cost structure and refusal to budge from older licensing models. Still there are very few applications that are more “sticky” than databases, which typically hold the keys to the kingdom. Financial institutions see their use of Oracle databases as almost a pre-requisite for compliance, although that perception may be changing

aws stage

Also new today, Amazon’s new AWS CodeDeploy, code-named Apollo, that the company said will enable rolling upgrades and ease deployments to multiple instances. It is available now, Jassy said, and will work with customers’ existing toolsets.

And , coming up early next year, AWS CodePipeline, a continuous test, build and integrate toolset. And AWS CodeCommit, a managed repository that lets you put your code where it can execute quickly with minimal latency.

This story will be updated throughout Andy Jassy’s keynote.


18 Responses to “Amazon declares war on Oracle (again) with new Aurora database”

  1. War? Maybe a small skirmish… It just continues to give MySQL relevance, so Oracle can extract support money from big companies.

    If AWS wants to go to war with Oracle, then it should build an “Aurora” with PostgreSQL which can actually compete with Oracle DB in term of feature set (better type system, CTEs, triggers, stored procedures, etc.).

  2. Seems much more likely this has to do with Microsoft’s Azure SQL Database as a service which is pretty much exactly as Aurora is described a relational database platform that can scale. yes this targets oracle types as well as hosted SQL and MySQL as those typically do not easily scale but comparatively this is azure SQL SaaS just in MySQL form. Should be interesting where the price lands compared to Azure.

    • Yuri Budilov

      We do indeed! Oracle has been overcharging the world for 20+ years and its time for it to stop. Microsoft SQL Server is also getting more expensive in latest (2012/2014) releases.
      MySQL is clunky even if cheap (and has warts) and it is really an Oracle product. Which leaves PostgreSQL and Aurora. What is required is full Oracle PL/SQL and MS-SQL T-SQL compatibility from a new AWS RDBMS (and from Google too?) and it needs to be rock-solid reliable as well as comparably fast/scale-able. Then customers will take the 1/10th of the price and run away with it. But only 100% API/SQL compatibility will do the job because shifting RDBMS applications from one platform to next is hard and Oracle takes advantage of that.
      Just saying!

  3. Seems highly unlikely that someone would dump an Oracle database to switch to something else. Switching datastores is really only viable in startups (to get some “why we switched from x press coverage) or very early on in projects.

    Much more likely the target here is to get new projects to start using it. i.e. it mirrors the switch from on-prem to cloud. Much easier to start with new projects than overcome massive inertia and time cost (and having to justify that time) to switch from something that already exists.

    Of course, if the price really is 1/10 the cost then that could be a compelling enough reason, especially when contracts come up for renewal!

      • it is really not that simple. For many customers, it is less a technology strategy vs. vendor strategy. If you look at Oracle , there are significant pieces of technologies that act as ‘pillars’ and ‘moats’ for the database including application, middleware, hardware, etc. For those that were ready to move on, they were planning on moving anyway, just a question of cost/timing/risk.

    • Not unlikely at all. It’s not uncommon to start with a commercial product when you’re using it on a small enough scale that your licensing costs are smaller that what it would cost to build in-house expertise; and then replace it with a solution that scales better financially if you get to the point where licensing costs exceeds that of your own team.

      Wisconsin Courts are a good example of a migration from a commercial database to Postgres when they reached the scale that it made more sense financially.

      • Any well architected solution can “easily” switch persistence stores. If you are tied to a specific RDMBS you are either doing something wrong, have a really old app, or are doing something very specialized (which is seldom and probably are using the wrong db).