As CockroachDB gets closer and closer to 1.x; I’ve been increasingly interested in using it for a project. I love what it promises to bring to the open source community, and database technology in general. It’s focus on scalability, durability, and consistency is especially appealing. However, as I ponder its utilization as a data layer for modern Internet facing applications, I start thinking about the SQL data model paradigm. I’m going to use a simple to-do app for my case study. Traditionally, when using a SQL database for this kind of app you would/could have a to-do table with at least the following columns (id[pk], list-id[fk], user-id[fk], done, description), with the associated user and task-list tables. This is simple enough, but it brings with it some obvious performance implications as the dataset grows. Of course this will be the first to-do app in history to become an Internet sensation, so there will be millions of task lists with a dozen or more to-do items each. With each user access, a query is performed on the entire table sorting out the correct owner, for each to-do item in their lists. While this example is a little silly, it does demonstrate how SQL may be a less desirable data organizational system for this type of mega multi-user app. Comparing this, to other data stores that offer data structures that can encapsulate the entire to-do list, and each to-do item in a single entity seems to be much more efficient. Some even offer user name spaces, while maintaining the same schema to help reduce query costs. That being said, are there any innovations that CockroachDB implements to help reduce the overhead of traditional SQL constructs? What would the ideal data model for this app look like in CockroachDB?