Ok. I gotta say, this looks too good to be true. We are getting our toes in the water with the sample Notes app, but are very pleased thus far. For years, I've been hearing how NoSQL is the way to go and I just cannot get my 56 year old RDB head around that idea. We deal with extraordinarily complex SQL queries and I am on about year 10 of trying to warm up to the idea that such things can be done efficiently with something as simple as key/value pairs. Every time I look into a demo, it's always a Hello World sample of DynamoDB or MongoDB and doesn't address the challenges of working with large and complex datasets with foreign keys, one to many relationships, 4th normal form, etc. But, I digress. The idea of having something like SST abstract away all of the Lambda, CodeDeploy, SQS, S3, CloudFront, DyanmoDB, etc. It's just overwhelming. Realizing that we can move forward on projects without needing to spin up, maintain, and understand EC2 Linux servers... Well, it's difficult to articulate how big a deal I think this is.

Welcome aboard Greg! If you haven't already, you may want to check out the NoSQL/DynamoDB talks by Rick Houlihan. He's an absolute master and regularly does deep dives into NoSQL data modeling using non-trivial data models and access patterns. He does AWS office hours on Twitch and they usually post the episodes to Youtube when they're completed. Fair warning, it's some next level stuff and is not for NoSQL beginners! But the content is amazing and may help for you to see more complex use cases beyond hello world (I know it certainly helped me).

^ second that content. But also if you have years of relational DB experience it's probably worth sticking with what you're good at. It's getting easier to use lambdas with relational databases and I think we recently crossed a good threshold

I had years of experience with typewriters when PCs came along and quite a bit of experience with fax machines before email. I'm trying really hard to fit the right tool to the job and not limit myself to my particular comfort zone.

Can we form a support group for those of us who understand the power of NoSQL databases, but constantly come across stakeholders in the workplace that say "We can't use NoSQL since our data is relational" <--- pet peeve of mine 🙂

Yeah it's just a tricky thing where I'm not sure if it's truly about right tool right job - feels more like what style clicks with you. I think both patterns have bridged the gap so they're generally viable choices for most things

I am 22 but for the last 10 years, 7 of them were spent modelling in relational designs. It is not easy to make the switch because you are used to thinking about not duplicating data and instead providing a reference such as an Id, which you can then use to lookup an item in another table. But with NoSQL, you are not concerned with physical storage costs and are responsible for ensuring your duplicated objects stay up to date. Let’s look at an example: Here we have an item in relational format: Order { id: String product_id: String customer_id: String } The non-relational format would instead the item like this: Order { id: String product: { id: String name: String price: Int } customer: { id: String given_name: String family_name: String } } Your application is responsible for ensuring consistency. So you need to design it based on asynchronous events as opposed to synchronous transactions. It is as a result of modern architecture that the NoSQL approach works better. If you are still designing your system architecture the old way, you will struggle to adapt your database design to work. It is the application architecture that dictates the database architecture mostly.