Hacker News new | ask | show | jobs
by magic_hamster 1439 days ago
If you have a database access layer then structuring your application shouldn't be that different. I wouldn't deal with the database directly unless I had a really good reason or the abstraction layer didn't support the query I was trying to run.
3 comments

DynamoDB is amazing, but not very flexible once you have designed your database. No abstraction layer will allow you to run queries ad-hoc in a performant way.
It’s true. 400kb max item size, too. 1mb max query size I believe. Good luck grabbing a shit load of data at once without a parallel scan.

Dynamo is a precision tool and it’s great at those specific workloads but it’s not a one size fits all by any means.

400kb is the max item size, the pattern to get around that is to store objects in S3 and URLs/keys to those objects in DDB
> No abstraction layer will allow you to run queries ad-hoc in a performant way.

Depends on the size of the data. Run analytics queries (i.e. things that return summary data not all rows) on 10GB of data through clickhouse or duckdb or datafusion and they'll generally return in milliseconds.

What does this have to do with DynamoDB? The point is that once you've gotten your data into DynamoDB, you're strongly limited in how you can use it until you load it into something else.
I didn't see an obvious connection between the two sentences.
An access layer doesn't change your access patterns, which is what actually determines the database model to use.

DynamoDB (and other similar key/value stores) make very big trade-offs for speed and scale that most applications don't need.

DynamoDB usage is heavily based around correctly structuring your keys. Allowing you to do things like query sub-sets easily. This in turn means you need to know what your usage patterns will be like so you can correctly structure your keys.

God help you if you need to make major changes to this down the road.

Database Access Layer can't do this for you, that just isn't what they do.