Part 2: The DynamoDB Book: An Interview With Alex DeBrie On His New Book

This is the second part of my interview with Alex DeBrie on his new insta-classic: The DynamoDB Book.

To read the first part of the interview please mosey on over to The DynamoDB Book: An Interview With Alex DeBrie On His New Book. Go ahead. Take your time. It's worth it.

Quick Fire Round. What's your quick reaction to:

The cost of storing data in S3 versus storing data in DynamoDB?

Use S3 for large blobs or data with a single access pattern. Also, amazingly, write-heavy workloads can actually be *more expensive* in S3 than in DynamoDB.

Amplify and GraphQL not supporting single-table design?

I’ve made my peace with it. Amplify / GraphQL are optimizing for different things than single-table DynamoDB design. That’s OK! Big fan of the Amplify team. Probably the most unique, ‘swimming-against-the-stream’ team at AWS, and I’d love to see more like it.

Should it take even an awesome 450 page book to learn how to use a database?

Now you’re forcing me to defend my honor! I think learning RDBMS from scratch would probably take 450 pages as well. It’s just that RDBMS is taught everywhere, incrementally, so you don’t see it all in one place.

NoSQL Workbench?

I really enjoy using it for making data models, showing examples, and serving as documentation for a repository. It’s much better than the Excel spreadsheet I used to use. The team is great and they’re continuing to iterate, so I’m bullish on it.

Aurora Serverless versus DynamoDB?

I once wrote a post about how Aurora Serverless is the future of data. My views have changed since then. If you’re betting on a database of the future, I think it’s a better bet that you can learn DynamoDB than to bet on making a serverless-friendly, pay-per-use, infinitely scalable relational database.

Is hand coding joins really better than materialized views?

You work with what you’re given! A lot of NoSQL seems very odd when you’re coming from a relational world, and it’s hard to break that mindset.

Is filtering on the client side a failure of the database?

It depends! I like to mention it because I think it forces you to think holistically about your problem. Not everything has to happen in the database layer.

You created a DynamoDB Wish List for AWS Santa. How is AWS Santa performing this holiday season?

Amazingly, they didn’t immediately implement my advice. Of my three biggest items, I think only one (more Redis-like operations) is likely to end up in DynamoDB, and even that might take a while.

If Rick Houlihan is an assassin, how many lives have been taken with DynamoDB?

We tried tracking this but we screwed up the aggregation logic in our Lambda function. Just know that it’s a large number.

Using the word “table” to describe something that’s more akin to a multi-dimensional wormhole than a table?

There used to be three hard problems in computer science: cache invalidation, naming things, and a highly-scalable, pay-per-use database that works with serverless compute. Just because the DynamoDB team solved the last one doesn’t mean they solved the second one.

Any truth to the rumor that Amazon.com has such horrible search capabilities because all their searches must be encoded with DynamoDB indexes?

Ha! I’ll just say that there are times when you can definitely see how DynamoDB’s limitations have influenced the UX in the AWS console.

How do you think AWS feels about needing the great Jeremy Daly to actually make their APIs usable?

I think it’s underrated how much AWS essentially outsources developer experience. And I think it’s a good idea! Let a thousand flowers bloom in the community. Most will fail, but a few will succeed. Formalize those, either by direct support of the community tool or by releasing a similar tool, and everybody wins.