Show HN: DBOS – Transactional Serverless for TypeScript Apps | Hacker News Reader

Show HN: DBOS – Transactional Serverless for TypeScript Apps

github.com

43 pointsKraftyOne17 comments

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/). 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) and our free-to-try serverless platform (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/

We’re here to answer any questions!

Open articleView on HN

I 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!

Thanks for your interest in DBOS! We talk more about how things work on this docs page: 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).

That 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?

Both 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 :)

Based 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.

Our 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.

Did you come before or after the other DBOS[1] ?

[1] https://dbos-project.github.io

Evidently 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

Huh, you're right. It did seem coincidental that just yesterday I saw something hyping Stonebreaker's new DB Operating System concept.

Hello! @otoburb is right (thanks!). We are the same group commercializing our DBOS research.

Good to see alternatives coming up to ridiculously complex serverside programming frameworks like SpringBoot, Node, etc etc.

How is Node ridiculously complex? It’s quite sparse.

Agree 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 ?

I browsed the documentation and saw no references to provisioning database compute/memory resources. Is the persistence serverless, autoscaling, and scale to zero?

https://docs.dbos.dev/getting-started/quickstart-cloud#provi...

Yes 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?

Thanks 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.

Reply on news.ycombinator.com