Amazon Goes After Oracle (Again) With New Aurora Database

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."

Comments

What's the Difference?

[gizmo2199]

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:What's the Difference?

[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.

Re:What's the Difference?

[DougOtto]

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:What's the Difference?

[mlts]

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:What's the Difference?

[Anonymous Coward]

Wikipedia's comparison of RDMS's

Oracle's comparison of MySQL and the Oracle database

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:What's the Difference?

[NotFamous]

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.

Re:What's the Difference?

[Charliemopps]

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 it. That's both good and bad. It saves you development time, and it lets you hire... well, to be frank, cheaper report guys. Even an idiot can write basic reports for Oracle. Move them to MySQL and they need to know what they are doing. It's not fixing anything for you. It also has it's downsides... you get lazy. I was writing reports in it for a few months for a project and I came back... oh, I can't do that here. That's right. Oh, I can't do a join like that... etc...

On the DBA side, Oracle makes some major tasks easier. Sometimes when I want to do some major things in MySQL I have to write actual applications or scripts to get the job done. Plan several steps, do them in the right order, etc... and some tasks like that in Oracle are just basic commands. Do X... it ticks away... done. That's nice. But again, it makes you lazy. Leads to you having staff that doesn't really know all the steps required to do X manually.

That said... I dont think any of that matters. Oracle costs insane amounts of money. MySQL (and a dozen others) is free. And the differences aren't that big of a deal. Any person that does Oracle should be able to get up to speed in MySQL or whatever, in no time. Those major operations that Oracle makes easy? How often do they happen?

The Oracle guys around me hate anything but it though. "Get a real database!" they say (for real) They have this general feeling that the company should fork over the cash for it so they don't have to bother with the trivial tasks they find annoying in the same way that the company should pay for free coffee. They seem to forget that if the company went with a free option they could literally triple every DBA and SQL guys salary and still save hundreds of thousands of dollars per year. That's how expensive Oracle is.

Re:What's the Difference?

[Whorhay]

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.

Re:What's the Difference?

[vux984]

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:What's the Difference?

[RabidReindeer]

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. In fact, one of the biggest security holes I routinely encounter outside of blatant SQL Injection comes from "clever" people who don't use the industry standard login and security mechanisms and invent their own.

Clue: I don't care if you ARE the Lord High Architect and Stephen Hawking routinely calls you when he needs help on hard problems. If you are not a full-time security expert with no silly distractions such as actual applications and if you don't have serious security training, DON'T try and invent your own security system. Use one that's already been vetted, proven, debugged and documented. By people who ARE full-time security experts.

Re:What's the Difference?

[LordWabbit2]

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).

Re:What's the Difference?

[Unordained]

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:Postgresql is no Oracle

[Zappy]

... The real question is what can you do in Oracle that you can't do in Postgresql. The answer is very little ...

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.