It says that the company is co-founded by Postgres creator. I find that bit hard to believe given that there is nothing novel in the article, probably discovery for them. I do understand that everyone has to go through their own journey to learn these things but at the same time when you are running business then seeking professional help isnt a bad idea.
Based on my experience queries like these cannot scale, whatever you do. However if you are already on a path where you had invested a lot in such queries then hire a DBA, if you are not far off then hire an architect to model the data for better performance.
My understanding (possibly flawed) is that Stonebraker isn't directly involved anymore.
The original idea that he worked on with the DBOS people at MIT and Stanford was very different and much, much more ambitious, which is why the name DBOS seems a little out of place now. The original idea was much closer to a "database OS".
Here [1] is the paper, which proposes that "To improve the scalability, security and operability of OSes, we propose a data-centric architecture: designing the OS to explicitly separate data from computation, and centralize all state in the OS into a uniform data model. In particular, we propose using database tables, a simple data model that has been used and optimized for decades, to represent OS state. With the data-centric approach, the process table, scheduler state, flow tables, permissions tables, etc all become database tables in the OS kernel, allowing the system to offer a uniform interface for querying this state."
The team later published another paper based on their prototype work [2].
Instead, they basically implemented Temporal as a client library with Postgres as the state layer. It's good, but only tangentially related to the original vision.
Maybe the long-term plan is an actual database OS, but it kind of looks like they decided they had to pivot to something much simpler, and slapped on an "for AI" like everyone is doing these days.
sandeepkd · · focus · HN ↗
Based on my experience queries like these cannot scale, whatever you do. However if you are already on a path where you had invested a lot in such queries then hire a DBA, if you are not far off then hire an architect to model the data for better performance.
atombender · · focus · HN ↗
The original idea that he worked on with the DBOS people at MIT and Stanford was very different and much, much more ambitious, which is why the name DBOS seems a little out of place now. The original idea was much closer to a "database OS".
Here [1] is the paper, which proposes that "To improve the scalability, security and operability of OSes, we propose a data-centric architecture: designing the OS to explicitly separate data from computation, and centralize all state in the OS into a uniform data model. In particular, we propose using database tables, a simple data model that has been used and optimized for decades, to represent OS state. With the data-centric approach, the process table, scheduler state, flow tables, permissions tables, etc all become database tables in the OS kernel, allowing the system to offer a uniform interface for querying this state."
The team later published another paper based on their prototype work [2].
Instead, they basically implemented Temporal as a client library with Postgres as the state layer. It's good, but only tangentially related to the original vision.
Maybe the long-term plan is an actual database OS, but it kind of looks like they decided they had to pivot to something much simpler, and slapped on an "for AI" like everyone is doing these days.
[1] <a href="https://arxiv.org/abs/2007.11112" rel="nofollow">https://arxiv.org/abs/2007.11112
[2] <a href="https://dl.acm.org/doi/10.14778/3485450.3485454" rel="nofollow">https://dl.acm.org/doi/10.14778/3485450.3485454