Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Cloud Businesses Data Storage Databases

Amazon Goes After Oracle (Again) With New Aurora Database 102

Posted by samzenpus from the brand-new dept.
Sez Zero writes with news about the latest from Amazon Web Services. "Once again Amazon Web Services is taking on Oracle, the kingpin of relational databases, with Aurora, a relational database that is as capable as 'proprietary database engines at 1/10 the cost,' according to AWS SVP Andy Jassy. Amazon is right that customers, even big Oracle 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 after typically contains 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."
This discussion has been archived. No new comments can be posted.

Amazon Goes After Oracle (Again) With New Aurora Database More

Amazon Goes After Oracle (Again) With New Aurora Database

Comments Filter:

  • What's the Difference? (Score:3)

    by gizmo2199 ( 458329 ) on Wednesday November 12, 2014 @04:56PM (#48372583) Homepage
    I'm a bit of a DB n00b, but know my way around MySQL. What's the difference between Oracle and MySQL for example. In my experience Oracle DBs tend to be a lot faster, than open source implementations. But is this inherently true, or is it all in the implementation, are there things you can do in Oracle that you can't do in MySQL, or MSSQL?

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      The real question is what can you do in Oracle that you can't do in Postgresql. The answer is very little, but there are must-have features that keep the biggest customers locked in.

      Having said that, Oracle must see the writing on the wall. They won't lose these most-entrenched customers but lots of middle tier customers are seeing the light (and massive cost savings are *really* enticing). Efforts like this from Amazon chip away even more.

      • I'm sorry, you are completely wrong. I work with big data, Postgresql and MySQL even MSSQL would shit bricks. The only two viable relational databases for large sets of data are DB2 and Oracle (with MSSQL limping in behind).

        • Thanks for keeping the OSS Oracle/Apple/MS haters in the real world. Oracle does have attributes that PostgreSQL can't match, for large datasets. The problem is that a almost none of the hackers here work with really large datasets. The other problem is that hardware is cheap. The data stored on them is so expensive as be irreplacable.

          That said, I use PostgreSQL for most projects because I don't HAVE really large datasets (I have a lot of small ones).

    • Re:What's the Difference? (Score:5, Interesting)

      by Doug Otto ( 2821601 ) on Wednesday November 12, 2014 @05:06PM (#48372687)
      If you're doing straight select, insert, update, delete operations there really isn't much functional difference between any of them. They all do locking a bit different and their are some syntax differences but it's all manageable.

      It's when you start looking at procedure code, triggers and such that MySQL(or Maria) is lagging behind in that thing get a bit wobbly. We've been looking at dumping Oracle for exactly the reasons mentioned in the article. Apparently Larry needs some new toys or something because they also seem to be going a bit 'audit happy' as of late. We're completely in compliance but it's taken dozens of man hours on our side to prove it. The worst part is there's really nothing you can do about it.

      • Re: (Score:3)

        by mlts ( 1038732 )

        Oracle is a mixed bag. One one hand, it is really nice to be able to get up and running without having to make sure you have every single license key somewhere. On the other hand, there are the audits.

      • ...Apparently Larry needs some new toys or something...

        s/toys/entire fucking islands/

      • One of the reasons why I avoid stored procedures wherever possible is because the convenience is outweighed by the vendor lock-in.

        Yes, there are times when you need the kind of performance that only complex server-based functions can provide Or times when no more distant means of access can keep a complex environment properly ACID.

        And when that's the case, I'll used stored procedures.

        But for run of the mill stuff, no. You end up with half the application in Java/C/.Net, whatever, and half in the database an

        • Yes that's why Aurora will not make any dent in converting companies from using Oracle db to mysql like databases. The barrier in conversion of stored procedures with complex business logic is formidable and Aurora does nothing to lower this.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Wikipedia's comparison of RDMS's [wikipedia.org]

      Oracle's comparison of MySQL and the Oracle database [oracle.com]

      Can't get much clearer than that.

      As to performance, I'd say it varies by application/configuration. I don't use Oracle myself, but last I heard, MySQL performed better in low-resource scenarios.

      • Yes that is correct. For commodity low end servers, mysql will perform much better than oracle in oltp typ transaction throughput. I did tests myself and saw 10X better performance with mysql vs oracle. Complex queries are different story however.
    • Oracle - MySQL = PL/SQL. PL/SQL is a full-blown programming language apart from ANSI SQL. There are objects, table variables, maps, arrays, etc. This is what makes it very hard to switch from Oracle. Once you have been bitten by the PL/SQL bug, it is very expensive to move away from.

      • There's also a HUGE ecosystem, very profitable, that after two dozen years, actually works-- expensive as it is. Oracle DBAs and SQL coders aren't the sort of person that's after the latest "edgy" new db scheme.

        I would venture that most of them don't like JSON, have no clue for hadoop, and are the online/never-fail sorts. They're not going to use REST against an AJAX app, are clueless about puppet, and believe in middleware. Not gonna get them to fix what they perceive as not-broken.

        There is a small amount

        • but like COBOL, mainframes/minis, and AS/400s/AIX, time will eventually pass them by, slowly, but unerringly, IMHO

          .... and they'll still be there. Grey and defiant.

          • So are 1957 Porsches. Some designs are timeless, but entropy will get them all but a few samples preserved for posterity.

        • There's also a HUGE ecosystem, very profitable, that after two dozen years, actually works-- expensive as it is. Oracle DBAs and SQL coders aren't the sort of person that's after the latest "edgy" new db scheme.

          I would venture that most of them don't like JSON, have no clue for hadoop, and are the online/never-fail sorts. They're not going to use REST against an AJAX app, are clueless about puppet, and believe in middleware. Not gonna get them to fix what they perceive as not-broken.

          There is a small amount of wisdom in this philosophy, but like COBOL, mainframes/minis, and AS/400s/AIX, time will eventually pass them by, slowly, but unerringly, IMHO.

          Well, that's a real shame, because my Oracle XML book's about 10 years old now. Presumably Oracle's done equivalents for JSON, and I'm pretty sure that they've got some AJAX tools in the mix, too.

          Not that I follow that stuff very closely. Most of the ReST, AJAX, and JSON stuff I've done is either in the general Oracle Sun Java libraries or from one of the major third-party suppliers such as Apache or CodeHaus.

          I'll grant that some people do dig their little hole in the ground and never get any bigger, but th

    • Re: (Score:2)

      by larien ( 5608 )
      As other posters have said, there are enough features in Oracle (some of which are added cost options) to keep it (or DB2, Sybase etc) mandatory in some cases because Postgres & MySQL simply aren't up to the job.

      Once you have that in play, companies will tend to standardise on one DB platform for most deployments because (a) you don't want to have to keep multiple skillsets up to date and (b) you never know when that new application will suddenly evolve into requiring feature X which MySQL doesn't supp

    • MySQL is a good example! I to do MySQL... but where I work, I'm the only one. Everyone else does Oracle. When they try to hit my database, they get all confused and come over to my desk. What on earth is going on?!!? I look at their SQL and say "This should never work. What on earth are you doing?!"

      After looking at this for a while, I then learned that Other forms of SQL, especially Oracle, fix your bad code. Not kidding... So code that should not work, the database figures out what you want to do and fixes

      • As a security oriented guy the big difference for me is the complete lack of built in security features in pretty much anything that isn't Oracle or MS SQL. MySQL is especially bad in this regard in my experience. Some agency will decide to switch to it because it's free and they expect a lot of savings. Then they discover that lots of the security features that were givens with Oracle or MS SQL just aren't there in MySQL. Sure they can license packages and whatnot to provide for those security options in

        • What security features, and are they present in PostgreSQL?

          I'm not sure why everyone automatically goes to MySQL as the only choice for open-source RDBMSes, when Postgres seems to be superior in every way.

        • As a security oriented guy the big difference for me is the complete lack of built in security features in pretty much anything that isn't Oracle or MS SQL. MySQL is especially bad in this regard in my experience. Some agency will decide to switch to it because it's free and they expect a lot of savings. Then they discover that lots of the security features that were givens with Oracle or MS SQL just aren't there in MySQL. Sure they can license packages and whatnot to provide for those security options in many cases but then it's not free anymore. They could write their own security packages, but again that will take a lot of time and money to develop, so not actually free. It could definitely end up cheaper in the long run but most program managers I've worked with don't seem to look at that as a viable sell to their customers.

          I have no idea what you're talking about. The MySQL server has extremely fine-grained security and it took me a long time to get happy with what it would let me do. Likewise for PostgreSQL. If the rules aren't just right, you can be bounced and nary a log message in sight to give a clue.

          Most of the major security issues I've seen in database-related systems had nothing to do with lack of security in the database (of which Oracle often makes headlines), but rather in the apps that are accessing the database.

          • The first thing that comes to mind with MySQL was the lack of automated account management. Yes, you can do it manually but that is inherently less secure than having an automated process that can be counted on to do things the same way every time.

            The last time I had to evaluate a MySQL database was around a year ago and there was a whole lot of "MySQL doesn't natively support that" coming from the MySQL expert. It is possible that the expert didn't know what he was talking about but each of the features th

            • Still unclear. The core account management DDL for MySQL is just about the same syntax as any other SQL-standard database, although you can also muck with the raw security tables if you prefer. Are you looking for an LDAP tie-in? Or maybe just a DDD (drag/drop/drool) GUI management tool?

              In general, you'll find that while Oracle and Microsoft offer a lot of stuff under their respective brand labels, FOSS projects usually spins off side projects from third parties. The net effect is about the same except that

        • Right, I'm not a security guy so that's not my problem though :-p

          My general response though is: The database shouldn't be doing the security.

          • That approach can work but as soon as you have any kind of compromise you've essentially handed out the keys to the kingdom. Defense in depth while a pain in the ass is effective in limiting the negative outcomes from security lapses. For instance would you be happy with a company that you did business with storing all your payment information in clear text because it was on a "secure" server? Defense in Depth says that regardless of how many security measures are in place between that data and the rest of

          • Re: (Score:2)

            by Cederic ( 9623 )

            So how the fuck are you securing the data at rest?

            How do you make sure that the OS admins can't see the data? How do you assure that people doing low-level data access (for performance or other reasons) can't see the data? How do you prevent a compromised app tier from seeing the data?

            The database shouldn't be doing ALL the security, but it had fucking well better be doing SOME.

      • I agree I worked at a company with a certified "oracle" expert that got paid big bucos and man was his code sloppy. Since the free ones don't troubleshoot or debug like Oracle you actually got to plan and do it right the first time lol Not sayin that's everyone...

      • Re: (Score:3)

        by vux984 ( 928602 )

        the database figures out what you want to do and fixes it.

        SQL is declarative not procedural.

        The entire raison d'etre for SQL in some sense is precisely that you tell it what you want and it figures out how to do it.

        Basically you've just criticized Oracle for being better at what SQL is SUPPOSED to be. :)

        • Did you really just say that Oracle fixing "what" you told it do makes it better at SQL, because SQL is about the engine figuring out the "how"?

    • "What's the difference between Oracle and MySQL"

      Well now that Oracle owns both, not much really :-)

      I've always felt that the biggest threat to Oracle has almost always been MS SQL Server, especially in the past few years. Unfortunately for MS, when they changed their licensing model with SQL 2012, the threat has waned to a certain degree.

      • Oracle only owns brand name "mysql". That's it. As for the code base, it can be forked and improved by anyone (e.g. mariadb, drizzle etc). If Oracle decides to deliberately slow down mysql development and try to kill it, it will not work. In the long term, I think mysql and other open databases will devour oracle's proprietary database marketshare.

    • There's also differences in administrative properties - such as access rights, how different users & schemas might interact, how database backups, replication, fail-over, mirroring, etc. all work. There's also subtle differences in some data types - such as what kind of date or time types are available, whether geographical information system (GIS) data types are available - and how much they might cost, etc. With older versions of MySql (5.1), you can have trouble joining the same table multiple time

    • I'm a bit of a DB n00b, but know my way around MySQL. What's the difference between Oracle and MySQL for example. In my experience Oracle DBs tend to be a lot faster, than open source implementations. But is this inherently true, or is it all in the implementation, are there things you can do in Oracle that you can't do in MySQL, or MSSQL?

      What's the difference?

      Mainly, for most customers, PRICE is the only real difference.

      It's not support, it's not functionality, it's not even performance (usually), it's about what you pay.

      For some customers, there are some unique features that Oracle brings or performance increases they have, but you pay though the nose for it. Usually the people that need these features can afford to buy from Oracle so that's what they do. There is some name recognition that gets your product into some place it wouldn't

    • Re: (Score:2)

      by jbolden ( 176878 )

      ASM = control your SAN volume manager from within the database
      Real Application Testing = simulate workloads
      Data Guard = pass databases offsite automatically as it is running
      Flashback = roll the database back to a arbitrary earlier points in time
      Index key compression
      Cluster tables = prejoin
      table and index partitioning = gigantic tables that go across disks and systems
      oracle vault = complex permissions for data with varying level of access that even dbas shouldn't have access to

      etc...

    • Re: (Score:2)

      by hey! ( 33014 )

      I've used Oracle (as well as practically every other major RDBMS platform) on and off since v4. Oracle has been around a long time and over that time it has acreted features and along with them complexity. For example it's got excellent features for storing and querying geographic objects. One of my favorite neat-o features is "virtual private databases" -- fine grained row-level security. You can set it up so some logins can't even see certain rows of a database -- e.g. if you log in as a regional manag

    • Not much. They both use joins, so they're not webscale.

    • I'm at re:Invent, and as they laid it out, the difference is in storage, read replication, and provisioning. Storage is in log-based files, and they've set it up so that crash recovery runs in seconds since the redo log playback runs differently. Storage is also all in SSDs. They've optimized read replication and between that and the log-based files, read replicas do very little write processing and are thus able to serve more read requests. Finally, it auto-provisions in 10GB chunks up to a max of 64TB

    • Re: (Score:2)

      by bondsbw ( 888959 )

      The difference? MySQL allows more than 30 characters for table/column names.

    • Nobody ever got fired from buying Oracle

      In all honesty the FOSS solutions at one time (~10 years or more ago) were not nearly as good as Oracle was, that created a snowball effect that people know Oracle, so they want to buy Oracle so the next guy who has to maintain it needs to know Oracle, so he wants to buy Oracle next time.

      It is kind of the same thing that keeps Windows inertia still going, database setup, configuration and maintenance are pretty much completely different across all databases, even the

  • For the kind of organisations that use Oracle, you do not switch unless you having a fucking big reason. People use oracle for things that have to run properly all the time, or the business goes bust. The CTO that desides to swtich the database better have bollocks the size of a small planet.

    For new projects maybe, but for the day to day running of the company, Oracle will not be shaking in their boots just yet.

    • Re: (Score:2)

      by mlts ( 1038732 )

      Oracle is expensive, but they have a niche that nobody else can take them from... where almost every application will work with Oracle as a DB backend. They are similar to AutoCAD in the safe bet regard [1]. Not because they are light years ahead of the competition... but they have ended up in a place where it is easier to pay for upgrades rather than switch to another RDBMS.

      Their only real competition in their market is DB/2 or maybe Sybase (because Sybase works as a backend to SAP.) For something used

      • Re: (Score:1)

        by Ed Avis ( 5917 )
        Don't SAP have their own RDBMS, called SAP DB or MaxDB? It was even released as free software a few years back (then they changed their mind and went back to proprietary). Do you mean that despite that, the only database backend that works well with large SAP installations is Oracle?

    • Re: (Score:2)

      by Cyberax ( 705495 )
      Yeah, sure. Like the banking systems of entire countries. Except that sometimes Oracle does crash...

  • If you look at AWS's actual announcement [amazon.com], they say nothing about Oracle. They say that Aurora is compatible with MySQL, which happens to be owned by Oracle, but it is not what most people think of as "Oracle"!

    What's my migration path from Oracle to Aurora? Does it support PL/SQL, XML, APEX, Java, etc. stored procedures? Does it support Oracle syntax, index types, etc? How sophisticated is its data dictionary?

    From AWS's announcement, it looks like Aurora is meant to be mostly a drop-in replacement for MySQL,

    • Re: (Score:2)

      by Shoten ( 260439 )

      If you look at AWS's actual announcement [amazon.com], they say nothing about Oracle. They say that Aurora is compatible with MySQL, which happens to be owned by Oracle, but it is not what most people think of as "Oracle"!

      What's my migration path from Oracle to Aurora? Does it support PL/SQL, XML, APEX, Java, etc. stored procedures? Does it support Oracle syntax, index types, etc? How sophisticated is its data dictionary?

      From AWS's announcement, it looks like Aurora is meant to be mostly a drop-in replacement for MySQL, but with much higher scalability and durability and more advanced backup features. If I had to call it something, I'd call Aurora "MySQL RAC", because Aurora seems to buy you more RAC-like features but with MySQL syntax/features.

      It absolutely does NOT appear to be an easy migration from an existing Oracle application to the Aurora database. Maybe Aurora will attract some new applications, but if you're a big Oracle customer, don't salivate on that 90% cost savings so quickly, because it ain't there!

      I think you don't understand how competitors get displaced in the IT market.

      Nobody is going to state that their product is a drop-in replacement when it comes to applications. It's not possible, it's never been true, and nobody would believe it even if it were. But Oracle has a huge number of extremely unhappy customers (direct and OEM) who hate their licensing cost and behavior (see the comment a bit of a scroll above about Oracle being "audit-happy"), and want another option. Oracle sells not just data

  • ... still use Sybase, and not some Johnny-come-lately like Oracle. Even for compliance stuff.

  • Nobody buys Oracle because they need a DB, and that sounds sexy. They buy Oracle because their application needs a database, and it either ONLY runs on Oracle, or is highly recommended to run on Oracle.

    And then there is Oracle commerce which I see nobody mentioning. The backend of most businesses, which shockingly needs an Oracle database.

    Got some random data you want to organize? have a budget? If so MSQL, otherwise MySQL. Have a real world app? Oracle.

  • Presumably when they OP author wrote "a relational database that is as capable as 'proprietary database engines at 1/10 the cost,' " what (s)he really meant was "a relational database (that is as capable as proprietary database engines) at 1/10 the cost".

  • The reason people aren't switching away with Oracle has nothing to do with the lack of cheaper alternatives.
  • ...in big-scale implementations:

    1. The existing high-profile customer base across industry domains which demonstrate high-availability, security, scalability and all the other attributes that organizations look for when choosing a database

    2. Vendor lock-in due to the myriad Oracle-owner applications that are strewn across an organization's IT landscape

    3. IT implementers who keep pushing technologies offered by the big-ticket ERP vendors such as SAP and Oracle

    4. The technical support that Oracle provides fo

  • Still there are very few applications that are more “sticky” than databases, which after typically contains the keys to the kingdom.

    DBs are rarely a problem. But DBAs and developers are the problem.

    I had limited to exposure to Sybase and MySQL, before spending several years with a company deeply tied to Oracle RDBMS.

    Most developers and DBAs are completely clueless about competitive alternatives. Over the years I have heard so much blatantly stupid crap, that it is even hard to believe that it can come from a person with higher education. MySQL can't transactions. Sybase locks completely everything for every update statement. You can

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close