On August 15, I presented a webcast about using the DBOS Transact library to compile application code into PostgreSQL stored procedures. The Good is that stored procedures can speed up application performance a lot. The Bad is that implementing and managing them can be prohibitively challenging. The Elegant is the way DBOS Transact eliminates those challenges, making it easier to build faster backends.
Here is the recording of the webcast, the slides I presented, and the answers to the questions asked by the live audience (below).
If you have questions, please ping me on the DBOS Community Discord; I'd love to hear from you!
Q: Can I use try/catch in the store procedure functions? How do rollbacks and error handling work?
A:Yes you can. In DBOS Transact applications, @storedprocedure functions return a JSON object containing the outcome of the stored procedure and supporting details, like success and result, or error and error detail, etc. I explain this at the 35:00 mark in the webinar recording video.
Q: How do you achieve such a dramatic cost saving vs AWS Lambda?
A: This is fully explained in this DBOS vs. AWS Lambda performance benchmark. DBOS is 15x more cost-efficient than AWS Lambda when executing transactional applications that orchestrate interactions with back-end databases or remote functions. Unlike AWS Lambda, DBOS…
- Is designed specifically for transactional use cases,
- Co-locates code execution with a DBMS to minimize latency, and
- Includes workflow orchestration with guaranteed, exactly-once execution.
Q: Is the compilation of the stored procedures performed using the same version of TypeScript that the application uses?
A: Yes.
Q: Will the Python version of DBOS Transact compile Python into stored procedures?
A: We are currently creating a Python version of DBOS Transact. We intend to support Python→Stored Procedure compilation as we do with TypeScript; but as of late August, we do not have a target release date for that capability yet.
Q: Are methods decorated with @Transaction also version controlled? What happens if you accidentally introduce a breaking change in the logic and there is a failed transaction of the old version in production that will be retried?
A: Yes the entire application is version controlled. DBOS Cloud always uses the correct version to execute, retry, and recover workflows, transactions, and communicators. This blog post describes how DBOS Cloud rolls new versions into production.
Q: How will DBOS maintain client libraries for many different languages in the future?
A: The DBOS Transact library is available for TypeScript and Python. We will implement the DBOS Transact library in additional languages, based on user demand. Join the DBOS community in Discord and let us know what language clients you require.
Q: I'm not quite familiar with stored procedures and DBOS, does Postgres automatically execute stored procedures under serializable transaction level or must you handle the transaction level you need within the stored procedure?
A: The DBOS Transact library allows you to specify the isolation level of @Transaction and @StoredProcedure functions. Details are in the docs: https://docs.dbos.dev/api-reference/decorators#transaction
