Client: *uses Oracle on AWS RDS*

Ora: *licence about to expire*

Client: we need a cheaper and equally performant solution.

AWS: we have an outstanding Aurora db! Its performance is flawless!

Client: shut_up_and_take_my_money.png

Engineers: *migrating to Aurora mysql*
Engineers: fine-tuning the db for 2 months, adapting app code.
Aurora: *shits its pants during test ramp-up, delivers ~70% of Ora perf*

==========

Client: we need to do better!

AWS: try Aurora Postgresql!

Engineers: *migrating to Aurora postgresql*
Engineers: fine-tuning the db for 1 month.
Aurora: *shits its pants during test ramp-up, delivers ~40% of Ora perf*

AWS: let me see...
AWS DBAs: *fine-tuning the db for another 2 months*
Aurora: *survives ramp-up, delivers ~70% Ora perf*

AWS DBAs: your application is wrong.
We: Ora didn't complain about that...

AWS DBAs: umm.. Err.. Then your load test is wrong
We: ora wasn't complaining about that either...

AWS DBAs: errr.. Ummm.. Oh, I've got it! Your queries aren't optimized!
We: we cannot change queried - they are hardcoded by our framework's vendor

AWS DBAs: well there you go! Your queries aren't optimized! It's your fault, not aurora's

yyeeahhhh... Riight...

From my xp, aws support and aws engineers ALWAYS try to put the blame on a client. Always. Even when they're obviously wrong.

That’s pretty much the polar opposite of my experiences with AWS

@100110111 I envy you. I trully do

@netikras Big difference between the bog standard and the enterprise support offering. You pay big bucks for the latter, but it's honestly the best support I've received from any enterprise company.

I'm a bit irritated about the 30 % margin...

It's seldomly that one database is a winner in all cases, variances exist and each database has usually their strengths and weaknesses.

The rest seems very plausible to me... As usually business customers get things promised by marketing without proof.

One of the reasons I dislike benchmarking in databases is exactly that. E.g. OLTP or other benchmarks that have nothing to do at all with what the client might actually do.

Databases are pretty much individuals, if you have an Oracle DB because of an program based on an Oracle Framework, ""just"" (as in only) changing the connection layer and making it compatible to another database is seldom enough. The majority of power comes from utilizing the DB specifics in DQL / Data Query Language. Eg. specifically optimizing for certain aspects of the databases Optimizer ;)

... Saying the queries aren't optimized isn't a full lie, but it isn't the full truth either.

If you _have_ an vendor lock in, be it Oracle, MSSQL or whatever, the full truth is that you need to eradicate it like in cancer treatment.

Nuke the shit out of it and bomb away everything with antibiotics.

This goes btw for any type of ORM, too...

The full truth is that usually a full audit, major rewrite and refactoring is necessary.... Databases have a lot of behaviourism.

Yeah I'm gonna call bullshit on this...

You don't "fine-tune" an AWS DB solution. That's the whole fucking point to use it in the first place.

If you have to fine-tune Aurora or otherwise, your app is shit and needs to be "fine-tuned".

My only problem with any Amazon DB solution is the surprise cost(which shouldn't really be a surprise). You're either going to be surprised by how cheap or by how expensive it will be.

@sariel oh, but you do fine-tune a DB :) Let me out it this way. Our application must handle loads, at which the beefiest AWS RDS instance is maxxing out every limit it has. At this point even the number of CPUs becomes a bottleneck, so we had to settle for an instance with less CPUs to get better performance.

DBAs we have are experienced ones. And yet it's the first project they see an Ora DB being under such a heavy load.

It's not application that needs tuning. It's been certified for Ora by our framework's vendor. It's good enough for Ora (regardless ORM being used). In the end, it's the DB that requires tuning.

@IntrusionCM I agree, 30% is not a lot. Yet it's too much for the SLA, especially when AWS claims it to be as performant as Oracle

> If you're using a commercial database such as Microsoft SQL Server or Oracle Database, Aurora can provide the same performance at one-tenth the cost.
ref: https://aws.amazon.com/getting-star...

I agree it could work better with aurora-speciffic hints in queries or whatever. But then again, Ora never needed such things. And the framework we're using has been also certified for Postgresql, meaning queries should be as good as it gets.

I'm ranting about AWS'es marketing and promises with forgotten asterisk(s).

@AlmondSauce the client has AWS Platinum Enterprise support (https://computerweekly.com/news/... says it's ~$15k/mo). And also client has their own liaisons in AWS. We should be getting the best AWS has to offer.

The 30% is what you save from not having to deal with Oracle anymore

@netikras sigh... They should crunch the numbers with an Abakus up their arse....

@ars1 Is that supposed to be a good thing? Why? IMO Oracle is an excellent DBMS.

@netikras Oracle certification only means that you're following their best practices and that you're going to use as many CPUs to give daddy Oracle Warbucks the largest payday.

If you're having troubles with load, you need to split your database up across different domains and run separate instances for each.

Again, architecture problems with your application not the database.

@sariel AFAIK RAC is not supported in RDS... Is it?

@netikras it's not, but you're trying to fix application problems with database solutions.

You're dealing with the pains of a monolith. Full stop.

You can't just do a lift-n-shift to a cloud provider without any changes to your app and if anyone told you it was possible, they lied.

Split the application models up into their domains, then split your DB up into those domains. Then correct your app models to reference the correct DB domains.

And before you shoot off about Oracle blah blah blah ask Oracle about their cloud hosting solution.

It's going to have the exact same problem, just more expensive.

@sariel it is possible, depending on the application of course, but the result is far suboptimal. However lift-n-shift is a better first step than no step at all. From there it is advisable to start an architecture modernisation journey toward cloud native solutions via minimum viable migrations.