[HN Gopher] Show HN: DBOS Java - Postgres-Backed Durable Workflows
       ___________________________________________________________________
        
       Show HN: DBOS Java - Postgres-Backed Durable Workflows
        
       Hi HN - I'm Peter, here with Harry (devhawk), and we're building
       DBOS Java, an open-source Java library for durable workflows,
       backed by Postgres.  https://github.com/dbos-inc/dbos-transact-java
       Essentially, DBOS helps you write long-lived, reliable code that
       can survive failures, restarts, and crashes without losing state or
       duplicating work. As your workflows run, it checkpoints each step
       they take in a Postgres database. When a process stops (fails,
       restarts, or crashes), your program can recover from those
       checkpoints to restore its exact state and continue from where it
       left off, as if nothing happened.  In practice, this makes it
       easier to build reliable systems for use cases like AI agents,
       payments, data synchronization, or anything that takes hours, days,
       or weeks to complete. Rather than bolting on ad-hoc retry logic and
       database checkpoints, durable workflows give you one consistent
       model for ensuring your programs can recover from any failure from
       exactly where they left off.  This library contains all you need to
       add durable workflows to your program: there's no separate service
       or orchestrator or any external dependencies except Postgres.
       Because it's just a library, you can incrementally add it to your
       projects, and it works out of the box with frameworks like Spring.
       And because it's built on Postgres, it natively supports all the
       tooling you're familiar with (backups, GUIs, CLI tools) and works
       with any Postgres provider.  If you want to try it out, check out
       the quickstart:  https://docs.dbos.dev/quickstart?language=java
       We'd love to hear what you think! We'll be in the comments for the
       rest of the day to answer any questions.
        
       Author : KraftyOne
       Score  : 30 points
       Date   : 2025-11-13 20:33 UTC (2 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | lukaszkorecki wrote:
       | Looks great, shame that due to annotation-based API it's gonna be
       | a pain to use in Clojure.
        
       | prasadaditya wrote:
       | Hey! Not a DBOS Java question but stumbled on this and looking
       | into it for the python client. Wondering what the support looks
       | like for integration w/ gevent?
        
         | stankygenki wrote:
         | Upvote on this! Currently building out a project using Flask
         | and gevent, and would love to use DBOS python with my Flask
         | gevent project
        
         | KraftyOne wrote:
         | DBOS Python works with gevent out of the box (sync DBOS uses
         | Python threading APIs and psycopg3 that gevent monkeypatches).
         | 
         | Have you run into any issues using DBOS Python with gevent?
         | Please let us know!
        
       | reecardo wrote:
       | We are increasingly using Temporal with Temporal Cloud and soon
       | Nexus to manage numerous workflows. I'm curious what type of
       | observability is avialable for DBOS and how much of that you get
       | for "free". The reason we ended up in Temporal was not that
       | previous job-systems were unreliable, it was simply that nobody
       | wanted to go dig through a database to find out what happened
       | with their job, and nobody has time/energy to build a UI just for
       | that purpose.
        
         | KraftyOne wrote:
         | There's an observability and workflow management UI:
         | https://docs.dbos.dev/java/tutorials/workflow-management
         | 
         | You can view your workflows and queues, search/filter them by
         | any number of criteria, visualize graphs of workflow steps,
         | cancel workflows, resume workflows, restart workflows from a
         | specific step--everything you'd want.
         | 
         | Currently, this is available as a managed offering (Conductor -
         | https://docs.dbos.dev/production/self-hosting/conductor), but
         | we're also releasing a self-hostable version of it soon.
        
       | nogridbag wrote:
       | Are there any plans for supporting other databases? Our company
       | primarily uses and has experience managing MySQL deployments. I
       | evaluated Temporal some time ago as it seemed like a good fit for
       | what we're building so I'm watching this closely. Thanks!
        
         | KraftyOne wrote:
         | Our primary focus is Postgres. DBOS Python recently added
         | SQLite support, we'll add this to other languages if it proves
         | popular, but no current plans for MySQL.
         | 
         | That said, while DBOS requires Postgres for its own
         | checkpoints, it can (and often is) used alongside other
         | databases like MySQL for application data.
        
         | qianli_cs wrote:
         | To build on what Peter said, we need to stay focused and make
         | one backend solid before expanding. But architecturally,
         | nothing prevents us from supporting more engines going forward.
        
       | rileymichael wrote:
       | glad to see the java sdk released, i've been watching the
       | discussion in the discord for a while.
       | 
       | one of the rough edges i've noticed w/DBOS is for workflows that
       | span multiple services. all of the examples are contained in a
       | single application and thus use a single dbos 'system db'
       | instance. if you have multiple services (as you often do in the
       | real world) that need to participate in a workflow.. you really
       | can't. you need to break them into multiple workflows and enqueue
       | them in each service by creating an instance of the dbos client
       | pointed at the other services system database. aside from the
       | obvious overhead from fragmenting a logical workflow into
       | multiple (that you have to push to the service instead of a
       | 'worker' automatically consuming the step), that means that every
       | service needs to be aware of and have access to, every other
       | services system database. also worth noting that sharing a single
       | system database between services was not advised when i asked.
       | 
       | (docs for the above: https://docs.dbos.dev/architecture#using-
       | dbos-in-a-distribut...)
        
       ___________________________________________________________________
       (page generated 2025-11-13 23:00 UTC)