Amazon’s Consumer Business Turned Off Final Oracle Database (aws.amazon.com)

Take that, Larry Ellison.

Now Amazon should do this to every company using them.

It's not really "switching relational DBs", it's "rebuilding all of the legacy systems to not use relational DBs". Their scale had long since left the realm where it was reasonable to run everything on massive monolithic DBs, but the technical debt hadn't been paid down -- so they just kept putting more money into bigger and bigger hardware and larger DBA teams to support them. For instance when I last worked the there each warehouse ran on a single massive Oracle DB. That isn't solved by swapping to another database; it was well beyond reasonable.

I suspect that this article seems like a bit of self-promotion but it's actually intended as a giant middle-finger to Oracle.

But that is not what happens.

First problem is - majority of mature enterprise systems (which tend to use Oracle), are not designed in such a schoolbook way, so that's you first problem. Codebases are ugly and teams loose the knowledge to maintain some parts that are mature and work mostly ok - often the DB layer.

Another concern is regressions in the product that is hard to properly test for. Minor details that are exposed by even small changes in DB behaviour or performance, that won't get caught in testing, but will cause an impact when your next scheduled job happens to fall on the first friday of that one month where the customer has that very special report that is just slightly so different and runs only once every 7 years.

Another major pain point are operational concerns. When dealing with DB technologies, managing, deploying, operating your back end DB servers can be quite a different beast. In theory your teams should be able to handle it, as they are experienced engineers that know how to learn new tech quickly. In practice, you don't have money for those, and your team is lazy and doesn't really want to learn that new cool tech, just let them do their job.

And finally, if it all "just works" at the moment, it is a hard sell to switch such a fundamental part of the system and properly validate the investment versus the risks.

And this is all if you're not a super user of Oracle specific pieces, surrounding tooling or consultants/expertise.

Whatever talent available in the company that wants to migrate off Oracle, would not want to take the risks of migration failure.

But you'll probably have Forms, Reports, and Apex too. These are all designed to make building an app a piece of cake but make it impossible to migrate except if you rewrite the whole thing.

Imagine what Oracle is going to try and charge Amazon per month for every remaining DB given how publicly hostile Amazon has been.

Why people can't admit that their opinions can be unpopular sometimes. That's not a bad thing. Not all the things you say need to be popular to have meaning to yourself and others. It sucks to be downvoted but that's part of having a healthy discourse in HN.

1. https://www.statista.com/statistics/250520/forecast-of-amazo...

> any functions in the order by clause must be moved to the select statement (e.g. order by lower(column_name))

I'd pull the hair outta my head

What does this refer to? AFAIK, you can invoke functions just about anywhere including in the ORDER BY clause:

    => CREATE FUNCTION some_func (int) RETURNS int AS $$ SELECT $1 + 1; $$ LANGUAGE SQL;
    CREATE FUNCTION

    => SELECT t.* FROM (SELECT 1 AS a) t ORDER BY some_func(t.a);
    a 
    ---
    1
    (1 row)

    => SELECT 1 AS a ORDER BY some_func(a);
    ERROR:  column "a" does not exist
    LINE 1: SELECT 1 AS a ORDER BY some_func(a);

PostgreSQL supports MERGE statements [1], and a cursory glance doesn't seem to show that Oracle deviates that much from the SQL standard. Is there a particular reason you are avoiding the merge statement or is it simply a readability preference for the non-standard "upsert" ON CONFLICT extension?

(I'm curious because I was a big fan of MERGE statements in a past life. Part of being allowed to use them in that codebase was proving that the standard was pretty well followed across DB vendors [not that we used more than one], as well as that MERGE performance was critical to some very large dataset joins with complex update logic.)

[1] https://www.postgresql.org/message-id/attachment/23520/sql-m...

For sorting on the result of a function, consider using a subselect. "SELECT foo FROM (select fun(z) as foo from blaz) tmp order by 1".

I hope they name it SADL Consulting.

rownum is a pseudocolumn numbering entries, sorting the results will give you records in non increment rownum. On such queries rownum <= N will give you the record that was first in the results before sorting.

LIMIT will give you the first record after sorting.

So rownum != LIMIT and if you really want to implement the same logic you would need to use select row_number() over () as rownum in the ported query, put that into a subquery and filter with where rownum <= N in the outer level.

Example:

select * from (select row_number() over () as rownum, * from pg_class order by relname) as x where x.rownum < 5;

select * from pg_class order by relname LIMIT 5;

Will give two very different results.

The first one maps to oracle:

select * from pg_class where rownum < 5 order by relname;

The second one doesn't.

Isn't that how everyone uses Oracle? I've seen exactly the same complains from developers at banks. Although building software around big featureful RDBMSs in general encourages poor architectures and messy software.