Amazon Goes After Oracle (Again) With New Aurora Database 102
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."
What's the Difference? (Score:3)
Re: (Score:2, Insightful)
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.
Re: (Score:3)
The one thing that keeps Oracle customers, especially the corporations, coming back to Oracle is that critical data can not be guaranteed if you use Postgresql or any other 'chicken branded' database engine
Correct one of the very few things you can do with Oracle compared to PostgreSQL is shunt the blame to them, while you might get the full blast when the same thing happens to PostgreSQL.
I have btw never see either of them fail at preserving your data.
Re: (Score:2)
Re: (Score:2)
I hate Oracle's pricing structure as much as anybody else
I doubt this. You aren't displaying the bitter despondency, psychopathic tendencies and desperation I feel when I have to deal with Oracle's licensing, and I know I'm relatively balanced on the matter compared to certain colleagues.
Larry, your customers hate you only mildly less than your staff, and you should try a spot of smalltalk to find out how lucky you are that none of them have snapped and caused another 2nd amendment debate.
Re: (Score:2)
PostgreSQL isn't the only kid on the block anymore, there are some great implementations to be made in other engines that could outperform Oracle for specific datasets. The problem is that Oracle (as said) is easy to 'certify' which usually means a beancounter can check off a box that means absolutely nothing in the real world.
Re: (Score:2)
Look at the value of an actual business. The hardware on which the database runs is cheap. The data is the product of all the work of all the people who worked there for the last 10-15 years, in the case of companies that do not manufacture things. Do you really think thay paying a couple of thousand Dollars even compensates for that? If you pay an average worked 60000 per year, and you have 200 of them, that is a 1.2 mil per year, and over ten years you gave out 120 million bucks. In comparison to that, th
Re: (Score:3)
You might check NuoDB, as that's their target audience.
RAC was indeed pretty cool. We did have to fight with the Ops guys, though, over the advertised auto-retry feature, which was dangerous for multi-statement transactions, and the documentation (at least at the time) didn't make that clear.
Re: (Score:3)
Re: (Score:2)
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: (Score:1)
I'm as big a postgres fan as the next guy, but there's still no multimaster replication.
Of course, unless you have millions of dollars to burn on Oracle, you're not going to get multimaster replication there either.
Re: (Score:2)
Re: (Score:2)
One of the most common underpinning infrastructures to the NoSQL databases is MySQL.
Oracle and DB2 may have virtues in certain circumstances, but they're a royal bitch to deal with, and in many cases, not worth the money, even in major shops for anything except the very largest applications.
From an administrative point of view, they're a joke. Ever tried to dump a DB2 database out to raw SQL using the IBM-supplied utilities? Ever tried to port a DB2 database from an iSeries machine to a Linux DB2 server? Or
Re: (Score:2)
You must be joking, right? Postgres can kick MySQL's ass, sure, but Oracle? For seriously large sets and reliability? No way!
Re:What's the Difference? (Score:5, Interesting)
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)
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.
Re: (Score:2)
...Apparently Larry needs some new toys or something...
s/toys/entire fucking islands/
Re: (Score:2)
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
Re: (Score:1)
Re: (Score:2, Informative)
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.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
So are 1957 Porsches. Some designs are timeless, but entropy will get them all but a few samples preserved for posterity.
Re: (Score:2)
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)
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
Re: (Score:3)
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
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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)
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.
Re: What's the Difference? (Score:1)
Re: (Score:3)
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. :)
Re: (Score:2)
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"?
Re: (Score:2)
"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.
Re: (Score:1)
Re: (Score:1)
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
Re: (Score:2)
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)
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)
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
Re: (Score:2)
Not much. They both use joins, so they're not webscale.
Re: (Score:1)
Re: (Score:2)
The difference? MySQL allows more than 30 characters for table/column names.
Re: (Score:2)
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
Re: (Score:2)
No, WAT is "which after typically". WTF is something else entirely.
Re: (Score:2)
You're quite right to point that out, Sir. The correct expression is "post-typically".
Will take years to tackle Oracle crown (Score:1)
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)
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)
Re: (Score:2)
Re: (Score:2, Interesting)
MySQL/MariaDB can't be positioned as a competitor to Oracle. It takes too many liberties with one's data. PostgreSQL on the other hand...
Re: (Score:2)
PostgreSQL lacks a lot of features needed to compete with Oracle, things like online index rebuilds and multiple active instances for HA are critical for many businesses where the option to take down the database or a table for maintenance isn't acceptable. Even MS SQL hasn't really been a competitor for many of these mission critical installs until SQL 2012 where finally MS is at near feature parity with Oracle, but they've stuffed up their licensing enough that there's now little incentive to move given a
Re: (Score:2)
Re: (Score:2)
Even with office suites, one could export whatever documents to some "standard" and switch to a new product, although some formatting would be lost/destroyed. For example, a document open in Pages, saved, then opened in LibreOffice would take some editing to have it formatted correctly.
Databases are permanent. Realistically, unless there is absolutely no other way to do it (for example, if the RDBMS program is written for a 16 bit OS), no company or organization will change database backends. It just tak
Re: (Score:2)
Re: (Score:2)
Finally... what about backups? Someone takes down some Amazon cloud servers, and the company using them is royally hosed. There are no tapes local, if there are backups on AWS or Glacier, they might be on the same datacenter or even the same SAN as the failed cloud servers. A conventional solution at least has the ability to have some tangible medium where the data is stored so it can be recovered.
This is basically MySQL, so you can make a backup like normal. With Amazon you can always store that backup in S3, and download that to a local server.
Re: (Score:2)
A few years back there was no shortage of competitors who claimed to do everything MS Office did (or Word, Excel, PowerPoint, etc) at 1/10 or 1/100 or 1/10**6 of the price.
Guess what product most people want to use today? Sounds like Amazon's Oracle killer is another OpenOffice or "Yeah, Write".
Hey, I use Open Office all the time on my Windows laptop... But I'm a confirmed penny pincher who has some IT experience.
But I think you miss the point that we are discussing infrastructure level stuff that the end user NEVER sees. So your example doesn't really wash. MS Office is entrenched because it's what people know and use at work, it's what they are used to. Who knows what relational database the application uses? Not the end user.
What's actually happening is Oracle is falling out of favor in new
Re: (Score:2)
Methinks the article sensationalizes! (Score:2)
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)
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
Real financial institutions... (Score:2)
... still use Sybase, and not some Johnny-come-lately like Oracle. Even for compliance stuff.
It's the apps, stupid! (Score:2)
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.
CWE-783: Operator Precedence Logic Error (Score:2)
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".
Amazon Misses Again (Score:2)
Reasons why Oracle rules the roost... (Score:1)
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
Not DB, people are the problem. (Score:2)
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