Re: Question on Aurora postgres - Mailing list pgsql-general

From veem v
Subject Re: Question on Aurora postgres
Date
Msg-id CAB+=1TXdkfK73+2fLmo7v0+2xD9jS_AyH9d5jEHYRQNTb58X_w@mail.gmail.com
Whole thread Raw
In response to Question on Aurora postgres  (veem v <veema0000@gmail.com>)
List pgsql-general
Thank you so much. So basically this application is an enterprise app with 24/7 users(doing DML and querying both) and is currently in Oracle on premise database. It has data in the range of ~20-30TB and the queries will be happening 24/7 on this database. It's an OLTP app. And ofcourse lower environment Dev/qa/uat doesn't have those kinds of usage and data volume as prod.

In the document below , I see a lot of instance types like Memory optimized X family, R family and T based instance class. So I'm a bit confused, how to get started with it, and if we can move from one type to another seamlessly if required in future? 

Will the cpu and memory, storage mentioned against each of these instance types be directly proportional to the CPU and memory size, storage size of data which we currently have on our on-premise oracle database? 


On Wed, 1 Nov 2023 at 04:55, Ben Chobot <bench@silentmedia.com> wrote:
veem v wrote on 10/31/23 2:49 PM:
Hello all,
We are planning to use aurora Postgres for a few applications. But wanted some guidance on which instance, class type should we use for lower environment/non prod like Dev/Qa/Uat/perf and what should we use for production database? Is there some recommendation based on usage etc. for this?

Regardless of if you are going to be making databases in a cloud provider or on physical hardware, the first step is to figure out what your load will likely be and what variables will be influencing it. Will you have a lot of data? Will it churn very much? Will you have a lot of concurrent reads? Will they be simple queries or memory intensive ones?

Only you can answer these questions, and once you have, the many (many) options available to you will start to separate out and there will be some obvious things to try. One of the great things about making databases in the cloud is that you aren't locked into any sizing choice like you can by if you go build a server.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Inefficient query plan for SELECT ... EXCEPT ...
Next
From: Dimitrios Apostolou
Date:
Subject: Re: Inefficient query plan for SELECT ... EXCEPT ...