5 ms·
Show HN: DBOS – Transactional Serverless for TypeScript Apps
Hello HN! We’re excited to show you DBOS, a transactional serverless SDK and platform that makes it easy to write fault-tolerant, observable, and scalable TypeScript applications.
We’re a startup commercializing research we did at Stanford and MIT. (https://dbos-project.github.io/ https://dbos-project.github.io/). The main idea behind DBOS is to store EVERYTHING about your application in the database. This gives you some unique features:
* Reliable execution – Your program’s execution state is stored in the database, so if it’s ever interrupted, it automatically resumes from where it left off without repeating any work already performed.
* Time travel – Every change to your program’s state is recorded in the database, so you can “rewind” time and restore the state of your application to what it was at any point in the past. For example, time travel debugging–take a tricky bug in production, rewind time, and reproduce it locally on your laptop.
Today, we released our open-source SDK (https://github.com/dbos-inc/dbos-ts https://github.com/dbos-inc/dbos-ts) and our free-to-try serverless platform (https://www.dbos.dev/dbos-cloud https://www.dbos.dev/dbos-cloud). We’d love for you to try them out and let us know what you think!
Here’s a quick guide to get you started: https://docs.dbos.dev/getting-started/ https://docs.dbos.dev/getting-started/
We’re here to answer any questions!
- catzapd 3y agoGood to see alternatives coming up to ridiculously complex serverside programming frameworks like SpringBoot, Node, etc etc.
- hestefisk 3y agoHow is Node ridiculously complex? It’s quite sparse.
- catzapd 3y agoAgree that Node is easier than SpringBoot, But Writing a simple app is easy. Not so for transactional app that needs to scale and be reliable and be fast. Add to it: docker Kubernetes Provisioning on cloud Log collection Observability ....... and much more You need a team of several engineers ?
- jghn 3y agoDid you come before or after the other DBOS[1] ? [1] https://dbos-project.github.io https://dbos-project.github.io
- otoburb 3y agoEvidently it's the same project, but your link was the "research & publish" phase of the project, while this announcements seems to be the "commercial" phase. The same list of people who wrote the blog post(s) on your research/publish link are listed as co-founders[1] on the commercial site. [1] https://www.dbos.dev/about https://www.dbos.dev/about
- jghn 3y agoHuh, you're right. It did seem coincidental that just yesterday I saw something hyping Stonebreaker's new DB Operating System concept.
- qianli_cs 3y agoHello! @otoburb is right (thanks!). We are the same group commercializing our DBOS research.
- bahador 3y agoI browsed the documentation and saw no references to provisioning database compute/memory resources. Is the persistence serverless, autoscaling, and scale to zero?
- achanda358 3y agohttps://docs.dbos.dev/getting-started/quickstart-cloud#provisioning-a-database-instance https://docs.dbos.dev/getting-started/quickstart-cloud#provi...
- bahador 3y agoYes but it says nothing about cpu/ram and/or memory/storage/io optimized hardware, cost per hour, or anything like that. Does it scale to zero? Does it autoscale? Will it throttle with spikes in load?
- KraftyOne 3y agoThanks for the good question! Our free tier offers fixed resources per application (under the hood, a Firecracker microVM with 512 MB of RAM and 1 vCPU) that scale to zero when not in use. For paid users, we'll offer autoscaling per application--we'll share more details on that soon.
- ibgeek 3y agoI love the idea, especially from reproducibility and debugging standpoints. It seems like there would be a significant performance hit, even if doing this on a single machine. If the application does external I/O, it seems impossible to reproduce state if it depends on the state of an external system. Can you give more details on the pros and cons and your ideas for ideal use cases? Thanks!
- qianli_cs 3y agoThanks for your interest in DBOS! We talk more about how things work on this docs page: https://docs.dbos.dev/explanations/how-workflows-work https://docs.dbos.dev/explanations/how-workflows-work For functions doing database transactions, we record execution information in that transaction, which isn't much overhead. For functions that communicate with external services, we record their output in the database and use the recorded output during recovery and debugging. We think DBOS is especially valuable for applications where reliability or security is a major concern (for example, in financial services or insurance).
- ibgeek 3y agoThat helps. Thanks! Giving the programmer control over the checkpoints make sense. Also, limiting it to “workflows” (not necessarily entire programs) and requiring that these be deterministic makes sense. I did some working with Folding@Home in grad school. All of the simulations would save their state to disk every N iterations to allow restarts. The state was relatively small (lots of compute, not a lot of data). The DBOS papers focused on implementing core OS kernel functionality on top of a distributed relational database. Trying to make a true distributed OS. This product seems like a pretty different direction (reliable execution and enhanced observability). Do your future plans tie back to the original project goals or are you going to keep going in a different direction?
- qianli_cs 3y agoBoth the academic vision and the commercial product are built around the same core idea: store as much application and system state as possible (ultimately, much of the state of the OS) in the database. This idea enables many of our platform's benefits, like reliable execution and time travel, and that list will only grow as we continue to build :)
- gregw2 3y agoBased on your Hello World app (TypeScript only seemingly), the mental model for writing apps on DBOS involves OO classes, async/await, annotations, and lots of punctuation. Any plans to support app development via using SQL? There are endless discussions on its limitations but a remarkably large developer base. What language(s) is DBOS really implemented in? With UNIX+C there was some synergy between the OS way of thinking and the appdev way of thinking and I am not really seeing that here. The node.js mindset and declarative SQL mindset are so different. Maybe it's the best you can do trying to cross OS+DB domains but would be curious to hear your thoughts or see a writeup of what drove your design decisions here.
- KraftyOne 3y agoOur goal in these design decisions is to make DBOS look familiar to developers by supporting one of the most popular stacks right now, building an application with TypeScript and SQL on top of Postgres. Under the hood of our cloud platform (mostly Go + SQL), we're building on ideas from the academic project to provide new features like reliable execution/time travel, but like a good OS, we want to hide that complexity from users.