Stately Cloud

Sea creatures evolve into crabs, databases evolve into DynamoDB Animals in the Ocean Evolve into Crabs In evolutionary biology there’s a concept called “carcinization”. Put simply, there is a trend towards different crustacean species evolving to have crab-like bo...

In a weird quirk of evolution, different crustaceans all end up evolving to look like crabs. Another convergent evolution is the inevitable march of database infrastructure towards something that looks like DynamoDB.

Don't think it'll happen to you? stately.cloud/blog/sea-cre...

The Future of Software Development is Agentic September 1993 marked the beginning of the end of the Internet as we knew it. But also its rebirth into something unrecognizable, new and wonderful. Prior to crossing this Rubicon, every fall brought ...

Developing software with agentic AI isn't the future - it's the present. Are our infrastructure tools, and especially our databases, ready for it? No way.

stately.cloud/blog/the-fut...

What do you think? Using a SQL database with those magic design patterns (no foreign keys, no joins, JSON documents). This slide is from Canva at #AWSreInvent keynote
🤔 Why not using a document database then?

Announcing an MCP Server for StatelyDB StatelyDB is the only database specifically optimized for change which makes it a natural fit for generative AI. We’re excited to announce our new Model Context Protocol (MCP) Server for StatelyDB tha...

What happens when you combine the power of an AI copilot with the safety of a schema that only allows you to make safe changes? Try it out with our new StatelyDB MCP server!

stately.cloud/blog/announc...

Bring Your Own Cloud Keeps You in Control of Your Data When StatelyDB first started out, we only supported fully-hosted databases run by us. Not only was it faster for us (and customers) to get started that way, it let us take on all the operational pain ...

How do you get all the advantages of a SaaS platform but still keep full control of your data, AND get to use your negotiated AWS discounts and committed spend? The BYOC deployment model is the solution to this common problem:
stately.cloud/blog/bring-y...

Reducing DynamoDB read costs by 60% using Sync As a NoSQL database, StatelyDB exposes all the classic CRUD APIs you’re used to - Put, Get, Delete, and List. But there’s one other core API that we think is a game changer - SyncList. To explain why ...

What's the best way to reduce cloud costs? Stop doing unnecessary work! I cut read costs for my application by 60% by syncing data instead of reloading it all. This is such a common and effective pattern that it was one of the first things we built into StatelyDB.

stately.cloud/blog/reducin...

Monitoring GitHub Action Runners with StatelyDB, AWS CDK, and Lambda Monitoring GitHub Action Runners with StatelyDB, AWS CDK, and Lambda At Stately, we’ve been hosting our own GitHub Action Runners on-prem which has given us a lot of flexibility and control over our b...

We've been hosting our own GitHub Action Runners but sometimes they go down. We whipped up a quick monitoring system that reports outages to our Slack. And we decided to go the serverless route and build using AWS Lambda with StatelyDB for persistence.

stately.cloud/blog/monitor...

No, for example if you have a temp volume mounted for some shared (ephemeral) state between pods, it thinks the pod isn't safe to remove ever. You have to add the 'cluster-autoscaler.kubernetes.io/safe-to-evict: "true"' annotation.

Oh, totally, but that's why it's autoscaling. Having someone turn a knob manually is a bad idea.

A screenshot of the paper "Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service" https://www.usenix.org/conference/atc22/presentation/elhemali

Figure 1 from the paper: DynamoDB timeline.

A good read on how DynamoDB has evolved over the past decade. DynamoDB was originally launched in 2012, and this retrospective paper was published in 2022. www.usenix.org/conference/a...

Some takeaways after reading it 🧵

That graph is after the 50% cost cut. Before it wasn’t even a contest.

Even in your example autoscaling helps - it will scale up during events and down when they’re not running. The only downside is you can’t scale all the way to zero, but you can scale to 1.

Don't forget to document all the reasons it *won't* evict pods even when you want it to...

Easy pagination is lowkey one of the best things about DynamoDB

Data modeling in DynamoDB is awkward. DynamoDB provides an incredible set of no-frills features for building apps and services. It has consistent performance at any scale. Very low operational pain. Simple cost model. Missing from that li...

DynamoDB is great for consistent performance, but getting started on it (or changing anything afterwards) can be difficult. What if it was easier to model your data in a way that sets you up for success and lets you sleep through the night?

stately.cloud/blog/data-mo...

And that's just writes - for reads provisioned capacity is still 50% the cost of on-demand.

That's fair, but provisioned capacity autoscaling is similarly set it and forget it.

What I'm amazed at is that even relatively "spiky" loads are cheaper with autoscaled provisioned capacity. In this graph yellow is the on-demand dollar cost, while the red is provisioned capacity cost.

DIM's been doing great since switching from Postgres to StatelyDB - costs are down and it's rock solid. I have a followup post coming soon that takes the wins even further.

I use a slightly different version saved as `~/bin/git-delete-merged-branches` so I can run it with "git delete-merged-branches":

#!/bin/sh
git branch --merged | grep -v "\*" | grep -v "^\s*\(master\|main\)$" | xargs -n 1 git branch -d

The `git branch --merged` is the most important bit.

Migrating Destiny Item Manager to StatelyDB Destiny Item Manager (DIM) is an open-source, community developed companion app for Bungie’s Destiny and Destiny 2 video games. DIM is extremely popular among Destiny players, with over 500,000 monthl...

What does it look like to migrate the backend for a popular web app to StatelyDB (and by extension, DynamoDB)? A better developer experience, more efficient querying, and less operational overhead: stately.cloud/blog/migrati...

They mention it briefly but a big gotcha is that the default hop limit for IMDSv2 is 1, but containers running in Kubernetes need it to be 2. So you must use a custom launch template in EKS to be able to use it at all.

I’m interested in your analysis here. Even with the recent price drop, we’ve found that any system that’s getting real traffic is probably still better off (read: gonna pay less) using autoscaling provisioned capacity.

Realistically I’d probably start with using tenant ID as a PK prefix rather than by itself - tenant is unlikely to be granular enough to be partitioned well.

I see what you meant initially, then. I was thinking about it more like how I gather requirements - as a subject matter expert, but using it as a tool to organize my thinking and then communicate what I’m doing to customers.

That AI generated nonsense diagram does not make me confident about trusting any of the information behind that link….

Obsessed probably isn’t good, but figuring out the actual requirements for a solution is - often moreso than the actual form of the solution. It’s also a great way to communicate, by asking “did I forget anything important this has to do?” Agreed that this shouldn’t take a lot of time and effort.

Glad it’s working out for you!

Yeah, it's basically just removing some of the constraints on the final transactional write.

We started with serializable (and optimistic concurrency control) - we figure it's the "most correct" and we can always expose looser levels later if there's a need.

We'd love to have your feedback! And I'm definitely interested in what you're storing that hits a 10GB limit. Partitioning by user is definitely the first recommendation we tend to make.

Part of the problem is that the web frameworks and databases folks are using when they're just getting started don't have any built-in guidance away from things like this. So if you don't know, what's to stop you from copy-pasting the wrong example from the Postgres docs or StackOverflow?