Amazon’s Consumer Business Turned Off Final Oracle Database

Don’t they claim some sort of copyright on the APIs and also restrict what can be called “Java”?

Obviously, enough Amazon bots are giving me bad karma, but my point stands: No, Amazon is not a special snowflake because it did this.

This was an expensive exercise in spite, took a long time and a lot of people - and everyone knows it.

They could have done this far efficiently already if they wanted to scale out, but that company has too many conflicting internal priorities that they took a heck of a long time to move away to anything that scales.

They never try to invent things and if not Oracle, they'd use some other vendor built software. That is the true reality of this company.

So no, if you're thinking you're better than this company for moving away from vendor built software, you are mistaken. In the worst possible way.

That said, if you restrict yourself to the PostgreSQL subset of Aurora, you will be able to move to any Postgres implementation down the line.

Yes, they charge you a fee to move your data off. However, that is not the limiting factor for people moving off of Oracle. (And if it is, they're probably not looking at AWS in the first place.)

I think the approach can be applied to many companies. I have seen some companies turning every single data storing problem into an Oracle problem. Amazon turned many of the problems into ones that are easier to solve. Using 6 different technologies[1]. I am sure not all applies to all departments but it is a better approach to do this at the scale they got. For small companies this really does not matter. If your hot data fits a single node disk cache you obviously won't benefit from using a horizontally scalable database but Oracle's customers are often in the higher end of the scale spectrum. The question is how can Amazon compete with Oracle where the relationship is there for decades between a customer and Oracle. Good example of this is banks. They managed to get some of the financial companies to move some workloads to AWS but to move Oracle workloads to something else is a whole different game.

1. https://media.amazonwebservices.com/blog/2019/bye_bye_oracle...

We've been working on migrating from Oracle to Postgres for a few years now. We are about 2 weeks from being finished. It is not for the faint of heart, but it is totally worth it. The documentation is much much better, performance is equivalent or better, the sql dialect is saner, etc. Other than moving the data itself (ora2pg was invaluable for this), rewriting the queries is what has taken the most amount of time. Some of our tips on differences between oracle and postgres sql:

replace nvl with coalesce

replace rownum replace listagg with string_agg

replace recursive hierarchy (start with/connect by/prior) with recursive

replace minus with except

replace SYSDATE with CURRENT_TIMESTAMP

replace trunc(sysdate) with CURRENT_DATE

replace trunc(datelastupdated) with DATE(datelastupduted) or datelastupdated::date

replace artificial date sentinels/fenceposts like to_date(’01 Jan 1900’) with '-infinity'::date

remove dual table references (not needed in postgres)

replace decode with case statements

replace unique with distinct

replace to_number with ::integer

replace mod with % operator

replace merge into with INSERT ... ON CONFLICT… DO UPDATE/NOTHING

change the default of any table using sys_guid() as a default to gen_random_uuid()

oracle pivot and unpivot do not work in postgres - use unnest

ORDER BY NLSSORT(english, 'NLS_SORT=generic_m') becomes ORDER BY gin(insensitive_query(english) gin_trgm_ops)

Oracle: uses IS NULL to check for empty string; in postgres, empty string and null are different

If a varchar/text column has a unique index a check needs to be made to make sure empty strings are changed to nulls before adding or updating the column.

PostgreSQL requires a sub-SELECT surrounded by parentheses, and an alias must be provided for it. - SELECT * FROM ( ) A

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

Any sort of numeric/integer/bigint/etc. inside of a IN statement must not be a string (including 'null' - don't bother trying to use null="" it won't work). Concatenating a NULL with a NOT NULL will result in a NULL.

Pay attention to any left joins. If a column from a left join is used in a where or select clause it might be null.

For sequences, instead of .nextval use nextval('')