From: | veem v <veema0000(at)gmail(dot)com> |
---|---|
To: | Ben Chobot <bench(at)silentmedia(dot)com> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Question on Aurora postgres |
Date: | 2023-11-01 04:09:47 |
Message-ID: | CAB+=1TXdkfK73+2fLmo7v0+2xD9jS_AyH9d5jEHYRQNTb58X_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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?
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.html
On Wed, 1 Nov 2023 at 04:55, Ben Chobot <bench(at)silentmedia(dot)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.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitrios Apostolou | 2023-11-01 13:32:51 | Re: Inefficient query plan for SELECT ... EXCEPT ... |
Previous Message | Tom Lane | 2023-11-01 00:52:07 | Re: Inefficient query plan for SELECT ... EXCEPT ... |