> 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.