Viewing profile — KraftyOne

This is something we mention in the third section of the article: dead tuples and autovacuum caused real performance hits, which we (partially) mitigated through index optimization…

The core optimization is to buffer notifications in-memory and send them in a batch instead of sending them as part of every transaction. So that's a general-purpose optimization f…

If you mean the optimizations coming in Postgres 19, the original post addresses this: > As an aside, there’s been some online discussion of a Postgres patch ( https://github.com/p…

To be clear, it's not a custom patch to pg itself, but an application-side buffering and batching optimization.

Outbox's power is that it turns an atomicity problem into an idempotency problem. You atomically write to the outbox, then you have an idempotent "workflow" that processes events f…

You still need idempotency for side effects outside your database, that's true (and fundamental to durability). But now you get exactly-once semantics for operations on your databa…

That's what the post is about! Once you're doing that, you really do have transactions between the state and the queue.

Every item will be written to the queue exactly once (as the update is transactional). Queue processing may need at-least-once semantics, yes, depending on what exactly you're doin…

You build a distributed system on top of this! For example, you may have many distributed workers durably executing workflows from the Postgres-backed task queue. The Postgres tran…

Yes, the core design is building a workflow system on a database--essentially, replacing the central orchestrator most workflow systems use with a Postgres database. This previous …

[dead]

The key is that the UDF's enqueue is transactional with the database update. Let's say the database update is inserting a new order. This provides the guarantee that if a new order…

Exactly! It's a distributed system, with many processes performing work in parallel, with a central database as a coordination point, used as little as possible. A mutex wouldn't g…

Unfortunately, DSQL is still lacking many core Postgres features (most notably foreign keys) that DBOS and DBOSify depend on. DBOS works with most flavors of Postgres though, inclu…

Take any Temporal example and swap the imports and connection strings, it's a drop-in replacement :)

We'd need DBOS in C# first! It's something we're considering for the future--if you're working in C#, happy to chat about it, reach out at peter.kraft@dbos.dev.

Exactly, Postgres as an orchestrator instead of a Temporal server as an orchestrator. This page goes into more detail (for DBOS, but DBOSify is the same principle but using the Tem…

I'm very sorry about this. I'll figure out why the form wasn't responded to. In the meantime, email me directly at peter.kraft@dbos.dev.

Yes it can (with documented exceptions)! The suite is here: https://github.com/dbos-inc/dbosify-py/tree/main/tests/confo... Here's the documentation: https://github.com/dbos-inc/db…