Re: Question on Aurora postgres

Поиск
Список
Период
Сортировка
От veem v
Тема Re: Question on Aurora postgres
Дата
Msg-id CAB+=1TXdkfK73+2fLmo7v0+2xD9jS_AyH9d5jEHYRQNTb58X_w@mail.gmail.com
обсуждение исходный текст
Ответ на Question on Aurora postgres  (veem v <veema0000@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Inefficient query plan for SELECT ... EXCEPT ...
Следующее
От: Dimitrios Apostolou
Дата:
Сообщение: Re: Inefficient query plan for SELECT ... EXCEPT ...