Finding Rigth Database

Most applications need to persist state. In a chat application, that state is massive, constantly growing, and high-frequency. The obvious starting point is a traditional RDBMS — but the specific access patterns of a real-time chat system eventually force a rethink. The Problem with RDBMS for Chat I could use PostgreSQL for storing messages. It works, until it doesn't. Chat is different from most relational data. Messages don't join to other tables. What I actually need is simple: insert a message, fetch messages by room or user. That's it. So the requirements are: It grows fast — millions, then billions of rows No joins needed — just "give me all messages for room X" Reads and writes need to be fast Traditional databases like PostgreSQL and MySQL weren't designed with this access pattern as the primary use case. Here's why that matters. Partitioning As the message table grows, we can partition it — split it into smaller physical chunks based on some key, like room ID or time range. Th