4 ms·

> The migration gave each internal team the freedom to choose the purpose-built AWS database service that best fit their needs, and also gave them better contro

> The migration gave each internal team the freedom to choose the purpose-built AWS database service that best fit their needs, and also gave them better control over their budget and their cost model. Anyone know of a comprehensive resource that we could use to figure out which DB to use?

zamalek 7y ago
R&D and engineering.
mooreds 7y ago
Depends on what you mean by comprehensive. https://aws.amazon.com/products/databases/ https://aws.amazon.com/products/databases/ is a good place to start. After that I'd do some PoCs or talk to a consultant.
jl6 7y ago
Here’s an algorithm which I believe to be 95% accurate: If only a single user/device needs to access the data: use SQLite. In all other cases: use PostgreSQL.
- dmix 7y ago
  At Amazon level you start needing specialized databases. For most other people Postgres is fine.
- haggy 7y ago
  Not sure how much sarcasm is built into your statement but as a long time user & supporter of Postgres I have to disagree. Postgres is fantastic at many things but there are times when it's not the best choice. An example would be high-scale OLAP. I've tried to use PG for those cases but ingesting thousands+ of events per second into PG and then trying to perform rollups on them in an online capacity (near real-time availability) requires a TON of extra legwork to get it going and near continuous maintenance thereafter. Other purpose-built DB's for OLAP such as Druid, Clickhouse, etc are much better suited for this type of use-case. The main advantage these systems have over Postgres is their column-oriented nature vs. row-oriented of PG and other RDMS.
  - wgerard 7y ago
    > Postgres is fantastic at many things but there are times when it's not the best choice. To be fair, that would be the 5% :).
  - jl6 7y ago
    Glib perhaps but no sarcasm intended. I do agree that there are use cases where PG loses out to more specialized tools, but that’s the 5%, and if you are in that zone you probably know you are and are likely to be capable of doing your own more robust evaluation.
  - Quarrelsome 7y ago
    on the similar MS stack of SQL Server it breaks down hard when you start trying to max its throughput. You have to start tearing down all the features, turning off indexes, foreign keys, etc. Otherwise what could take hours will take days or even weeks.
- TimTheTinker 7y ago
  If provisioning and maintaining MS SQL Server is more of a happy path for your IT department, that's not a bad choice either.
onefuncman 7y ago
The og-aws Slack or ##aws on freenode But really, you should understand what kind of data store you need based on your use case is first and then decide on an implementation later...
deleted 7y ago
[deleted]
twic 7y ago
http://howfuckedismydatabase.com/ http://howfuckedismydatabase.com/

zamalek 7y ago

R&D and engineering.

mooreds 7y ago

Depends on what you mean by comprehensive. https://aws.amazon.com/products/databases/ https://aws.amazon.com/products/databases/ is a good place to start. After that I'd do some PoCs or talk to a consultant.

jl6 7y ago

Here’s an algorithm which I believe to be 95% accurate: If only a single user/device needs to access the data: use SQLite. In all other cases: use PostgreSQL.

dmix 7y ago
At Amazon level you start needing specialized databases. For most other people Postgres is fine.
haggy 7y ago
Not sure how much sarcasm is built into your statement but as a long time user & supporter of Postgres I have to disagree. Postgres is fantastic at many things but there are times when it's not the best choice. An example would be high-scale OLAP. I've tried to use PG for those cases but ingesting thousands+ of events per second into PG and then trying to perform rollups on them in an online capacity (near real-time availability) requires a TON of extra legwork to get it going and near continuous maintenance thereafter. Other purpose-built DB's for OLAP such as Druid, Clickhouse, etc are much better suited for this type of use-case. The main advantage these systems have over Postgres is their column-oriented nature vs. row-oriented of PG and other RDMS.
- wgerard 7y ago
  > Postgres is fantastic at many things but there are times when it's not the best choice. To be fair, that would be the 5% :).
- jl6 7y ago
  Glib perhaps but no sarcasm intended. I do agree that there are use cases where PG loses out to more specialized tools, but that’s the 5%, and if you are in that zone you probably know you are and are likely to be capable of doing your own more robust evaluation.
- Quarrelsome 7y ago
  on the similar MS stack of SQL Server it breaks down hard when you start trying to max its throughput. You have to start tearing down all the features, turning off indexes, foreign keys, etc. Otherwise what could take hours will take days or even weeks.
TimTheTinker 7y ago
If provisioning and maintaining MS SQL Server is more of a happy path for your IT department, that's not a bad choice either.

onefuncman 7y ago

The og-aws Slack or ##aws on freenode But really, you should understand what kind of data store you need based on your use case is first and then decide on an implementation later...

deleted 7y ago

[deleted]

twic 7y ago

http://howfuckedismydatabase.com/ http://howfuckedismydatabase.com/