Thread First – a model for all chat experiences (progressdb.dev)

A thread-first chat model reframes conversations by treating the thread—not individual messages—as the primary unit of organization. Instead of each message owning replies, reactions, metadata and relationships, messages become monotonic entries (timestamp or counter) keyed by thread_id, while participation and ownership live separately. That simple shift removes a lot of schema sprawl and migration pain: it cleanly supports 1:1, group, broadcast, federated and bot/assistant modes without adding bespoke collections or hacky joins every time you introduce a new feature. For teams building AI-enabled chat features (summaries, assistant outputs, shared threads), it standardizes behavior and evolution across contexts, reducing operational complexity. The hard part is storage: most SQL/NoSQL systems flatten threads and then rebuild order with indexes and joins, causing random IO and inefficient range scans. A true thread-first system needs contiguous prefix-based appends and reads so scanning/replaying a thread is a single range scan. LSM-based KV stores (RocksDB, Pebble, LevelDB) naturally provide lexicographic ordering and efficient range scans; in-memory approaches like Redis streams get close but trade off persistence and long sequential scans. The takeaway: modeling threads right is only half the solution—the storage engine must natively preserve adjacency and order for the model to deliver its simplicity and performance.