I kind of agree at least for a huge amount of code that mostly schleps data around according to rules. The data should be at the center with the code orbiting it, not off to the side.
This really doesn't look as cool as it sounds. The title / header reminds one of operating systems of the past; attempts to have the OS as database like OS/400, but the reality seems far more like a cloud hosted Linux + Postgres + Node/TS + Temporal (or something like it). As in, nothing to see here that we didn't already trivially have. Is there more to see besides the rock star at the helm?
Hi there! I'm from DBOS :) Just wanted to clarify that we don't use Temporal internally.
We provide strong guarantees (like exactly-once transactions) and new features (like database time-travel, you can replay any production trace in a local dev environment). We also believe there's a lot of value in the ease-of-use and simplicity that comes from our architecture: it takes only a few minutes to deploy an app to the cloud.
Yikes...the gobbledygook that passes for a code-example on the home page is not exactly an advertisement.
await ctxt.invoke(Shop).
is repeated 5 times in what I'd say are about 7 active lines of code. Then, because it's so unreadable, you have a comment per line that needs to explain what the line does. Hmm..
Anyone who took the time to actually check this out can see that it's just TS over postgres with muddled logic and arbitrary features that seem to try to solve problems that only vaguely exist.
The code examples indeed demonstrate exactly the sort of confusion that the entire product screeches.
Just seems like a way to rope people into a service (DBOS Cloud) they don't actually need (which may or may not be expensive, as information regarding this service is greatly lacking.)
Perhaps it's true that this is a project in the early stages, but with the heavy-handed sales language baked into the site, perhaps it was announced a bit too early..?
I'm not sure why you think these solve problems that only vaguely exist. If the claims they make are true, it's basically AppEngine+Cloud SQL, but in a package that makes every line of code trivially transactional and replayable. That addresses problems literally everyone has.
The "contact sales for pricing" is a plague, especially for companies that are have that specific Northern American attitude. While I hate it, I don't see it being much different from a lot of IT space.
I did a lot of research and product evaluations, was always honest about my intent and how much decision power I had. It worked out maybe once - most companies insisted on wasting time of multiple people just to ... Waste even more time and not give even unofficial rought estimate, or basic definitions from license. It kind of matters if it's paid for "every employee" or "every employee that uses the software". Apparently just for me.
look, I know this thing is obviously the second coming, or new sliced bread or something, but the dupes are just out of control: https://hn.algolia.com/?q=dbos and that's not even counting the submissions of blog posts about their hot new thing from the employees
We got it, it's awesome, stop making NEW THREADS where everyone who wasn't in the first 500 of these submissions posts the same things
Michael Stonebraker is very smart. I remember using his VoltDB back in 2012 (from memory) when NoSQL is all the rage. I wonder if VoltDB is the core of DBOS?
At the risk of making a classic "I have a few qualms with this app" blunder, I'm not super clear on what this has over other durable workflow solutions.
It seems to take the durable workflow idea and lock you into a specific language, operating system, and database, when other projects in the same space give you choice over those components.
Co-founder here. Thanks for the questions! A couple advantages DBOS has:
1. It's a serverless platform. It manages application deployments, providing a simpler experience than trying to bolt a durable execution framework onto an app deployed on Kubernetes.
2. Transactional guarantees. DBOS does durable execution in the same transactions as your business logic, so it guarantees exactly-once execution for most operations while other workflow solutions are at-least-once. More details here: https://docs.dbos.dev/explanations/how-workflows-work
> Linux is legacy code at the present time and is having difficulty making forward progress. For example there is no multi-node version of Linux, requiring people to run an orchestrator such as Kubernetes.
I can run linux on a raspberry pi. I can run kubernetes on a raspberry pi (if I wanted to). Can I run DBOS on a raspberry pi?
Also, there is the ambiguity of exactly what "multi-node" entices. Kubernetes is basically orchestration on top of a high-level segmentation of a node's resources. This is basically as vague as people want.
Damn, Stonebreaker, Zaharia. Seems like the big guns are out for the new data model in town.
This tech feels like fancy RDBMS triggers backed (and made unique) by a distributed log. Looks very much like the same tech as Flink's statefun and Restate.dev.
Just like SSD gave us LSM trees and RocksDB, it seems like this is the higher level abstraction that Kafka enables. It's going to be interesting to see how it pans out.
A lot of DB optimizations are almost invisible to the user, yet have a profound impact on performance. Like what Omnigres does with their query caching feature.
DBOS will definitely be an interesting thing to watch out for, if it looks to make things available at a low level.
The DBOS SDK can deploy your transactional, fault-tolerant TypeScript code locally (any platform) for testing purposes. For production deployment, deploy your code from the SDK to DBOS Cloud
But that is for DBOSCloud, but I guess it goes for DBOS as well?
I doubt he remembers me. In any case even back then he would say that the database should just do everything in our staff meetings.
Many of us were smirking back then each time it came up, but it looks like now, 20 years later, he is finally having a go at it!
He is one of the smartest people I have ever met - as far as I can tell :) So if there's someone who can do it, it is him and the team he assembles.