Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Just make it scale: An Aurora DSQL story

allthingsdistributed.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Just make it scale: An Aurora DSQL story

#21

Post by EwanToo »

pzduniak wrote: post #4
glzone1 wrote: post #2

Early dsql had some weird limits I think - anyone actually using in production with feedback on current corners and limits?

Who would use Preview products in production? I'm building out some software that would fit perfectly into the constraints set for DSQL, but I realistically can't commit to something with no pricing / guarantees.

This blog post appears to be part of the scheduled launch marketing, it's now generally available

https://aws.amazon.com/blogs/aws/amazon-aurora-dsql-is-now-g...

Re: Just make it scale: An Aurora DSQL story

#22

Post by loginatnine »

mjb wrote: post #6
glzone1 wrote: post #2

Early dsql had some weird limits I think - anyone actually using in production with feedback on current corners and limits?

Which features would you like to see the team build first? Which limits would you like to see lifted first? Most of the limitations you can see in the documentation are things we haven't gotten to building yet, and it's super helpful to know what folks need so we can prioritize the backlog.

Views and foreign keys!

Re: Just make it scale: An Aurora DSQL story

#23

Post by mjb »

loginatnine wrote: post #22
mjb wrote: post #6

Earlier quoted context omitted.

Which features would you like to see the team build first? Which limits would you like to see lifted first? Most of the limitations you can see in the documentation are things we haven't gotten to building yet, and it's super helpful to know what folks need so we can prioritize the backlog.

Views and foreign keys!

Thanks. The team's working on both. For views, do you need updatable views, or are read-only views sufficient?

Re: Just make it scale: An Aurora DSQL story

#25

Post by tigy32 »

kikimora wrote: post #18
geodel wrote: post #14

Earlier quoted context omitted.

Well Java need it because it fragments memory a lot. With Rust one has value types and stack allocation which takes care of one of the biggest cause of fragmentation.

Writing code that would not fragment memory over time is arguable much harder than writing GC friendly code.

I haven't found that to be the case in my experience: just for example in java you tend to end up with essentially a lot of `Vec>` which causes a lot of fragmentation. In rust you tend to end up with `Vec` where `Thing`s are inlined. (And replace Vec with the stack for the common case). I find it more like Java is better at solving a problem it created by making everything an object.

Re: Just make it scale: An Aurora DSQL story

#26

Post by tigy32 »

loginatnine wrote: post #24
mjb wrote: post #23

Earlier quoted context omitted.

Thanks. The team's working on both. For views, do you need updatable views, or are read-only views sufficient?

For me it's RO views.

I believe views were added to the preview a little while ago

edit from the launch: "With today’s launch, we’ve added support for AWS Backup, AWS PrivateLink, AWS CloudFormation, AWS CloudTrail, AWS KMS customer managed keys, and PostgreSQL views."

Re: Just make it scale: An Aurora DSQL story

#27

Post by mjb »

tigy32 wrote: post #26
loginatnine wrote: post #24

Earlier quoted context omitted.

For me it's RO views.

I believe views were added to the preview a little while ago edit from the launch: "With today’s launch, we’ve added support for AWS Backup, AWS PrivateLink, AWS CloudFormation, AWS CloudTrail, AWS KMS customer managed keys, and PostgreSQL views."

Correct: https://docs.aws.amazon.com/aurora-dsql/latest/userguide/wor...

Re: Just make it scale: An Aurora DSQL story

#28

Post by [deleted] »

SahAssar wrote: post #7
geodel wrote: post #5

Good read. I like the part that both writing low level as well as high level component in Rust was proven worthwhile. Maybe one can transform slow code from high level languages to low level language via LLMs in future. That can be nice performance boost for those who don't have Amazon engineers and budgets

> Maybe one can transform slow code from high level languages to low level language I think you are describing a compiler?

[deleted]

Re: Just make it scale: An Aurora DSQL story

#29

Post by tomComb »

mjb wrote: post #6
glzone1 wrote: post #2

Early dsql had some weird limits I think - anyone actually using in production with feedback on current corners and limits?

Which features would you like to see the team build first? Which limits would you like to see lifted first? Most of the limitations you can see in the documentation are things we haven't gotten to building yet, and it's super helpful to know what folks need so we can prioritize the backlog.

The lack of JSONB is what stopped me.

Re: Just make it scale: An Aurora DSQL story

#30

Post by kondro »

It would be really great to get more context on what a DPU is for pricing: https://aws.amazon.com/rds/aurora/pricing/

I understand that AWS did one TPC-C 95/5 read/write benchmark and got 700k transactions for 100k DPUs, but that’s not nearly enough context.

There either needs to be a selection of other benchmark-based pricing (especially for a primarily 50/50 read/write load), actual information on how a DPU is calculated or a way to return DPU per query executed, not just an aggregate CloudWatch figure.

We were promised DSQL pricing similar to DynamoDB and insofar as it’s truly serverless (i.e. no committed pricing) they’ve succeeded, but one of the best parts of DynamoDB is absolute certainty on cost, even if that can sometimes be high.

Post reply on HN