<@U01PSS0ETUH>: I saw this message and it made me ...
# general
m
@Omi Chowdhury: I saw this message and it made me question this approach. Given that DynamoDB pricing model is based on number of units (KB?) read/write, doesn't this mean that 1 single table (with a lot of attributes for different use-cases) will cost a lot?
s
In theory yes. The table needs to be well designed to optimize costs. Write Capacity Units (1kb) and Read Capacity Units (8kb) are the billing medium. There are some great materials out there to familiarise yourself with these design concepts. This one and the related video are probably some of the best IMO https://www.trek10.com/blog/dynamodb-single-table-relational-modeling
o
Yeah, if you’re duplicating a lot of data to pre-join things, or using a lot of GSIs, your storage costs will be higher (although its impossible to make a general statement on whether it’d be higher than storing it in a relational DB). Might end up costing less depending on usage patterns, might cost more but worth it.
Friend of mine at a large hiring platform (100s millions of job postings) tried out dynamodb and didn’t adopt it because of cost - because their items - which are mostly HTML - are very large. They ended up using elastic search instead as the primary store instead of only using it as a secondary search index.
t
The other thing to consider that's not often factored in is management overhead. Relational DBs will surprise you every once in a while where some feature grew in an unexpected way and requires maintenance (add index, refactor code, or update data models). These surprises cost your team a lot of time especially when they delay other planned work. DynamoDB will give you a consistent experience at every scale and that reliability really saves money when you think in terms of engineering time
j
Yeah having struggled with scaling MySQL in a past life I’ll echo this as well. That said, if you think this is going to be a small project in scale, maybe it’s not worth learning something new.
d
Limited experience here with dynamodb/nosql. So to ensure data integrity - data types/schema/"joins", is that logic usually all done in the application code, in the form of mongoose/typeorm/etc?
o
Yeah my tool of choice is
dynamodb-toolbox
. Basically build a lib to wrap it with higher level functions that implement those type of constraints on my app’s specific data model (that lib also implements dataloader and logging)
s
In my own experience yes. DynamoDB toolbox is a good one for nodejs https://github.com/jeremydaly/dynamodb-toolbox. It also helps with some of the creation of complex updates.