> The obvious caveat here is any situation where you need global tables A lot of people still end up storing data that's not frequently updated in a traditiona

> The obvious caveat here is any situation where you need global tables A lot of people still end up storing data that's not frequently updated in a traditional OLTP database like Postgres. However: I think it always helps to think about these problems as "how would you do it in Cassandra/DynamoDB?" In the case of Cassandra/DynamoDB, the relevant data (e.g. user ID, channel ID, etc) is always in the partitioning key. For Durable Objects, you can do the same thing by building a key that's something like: ``` // for a simple keys: env.USER_DO.idFromName(userId); // or for composite keys: env.DIRECT_MESSAGE_CHANNEL_DO.idFromName(`${userAId}:${userBId}`); // assumes user A and B are sorted ``` I've spoken with a lot of companies using _only_ this architecture for Durable Objects and it's working well.