Another fascinating fact: our countries TLD has been stolen Ocean's 11 style (I am not kidding). After Czechoslovakia split into Czech Republic and Slovak Republic, the newly created Slovak .sk TLD has been under the care of people from the local university. The university also had some offices that they were leasing out. Someone had leased this office space (EDIT: this is important as this means they had the same physical address), created a company that had the same name as the NGO that was taking care of the domain, so e.g. the NGO was named "My Company o.z." and the perpetrator created a "My Company s.r.o." (our countries version of the american Ltd). This person then wrote to ICANN to change the address to the "My Company s.r.o." presumably under the pretense that this was just an administrative error and from this point, they have functionally taken custody of the TLD. I was not able to find how they did it technically, but I presume they persuaded ICANN to then point to their servers instead of the real ones. After this happened, it seems that no one noticed for some time. When they noticed, they tried taking it back, but they weren't able to. For some inexplicable reason, the government during that time (Šuster era, early 2000s) gave the new company a contract that was functionally uncancellable from the government side. Later governments made this even more uncancellable and in 2017, then Minister of IT (and as of this day president!) Pellegrini made the contract literally uncancellable. As a result of this, we have one of the most expensive domains around (18e/year, rising each year for no good reason). (EDIT:) The company running our countries TLD is now a foreign entity that the whole thing has been sold to (multiple owners over time) and we as a country have no control over if I understand it correctly.
I might have gotten some details wrong as I am writing this from my memory of researching it a couple of years back, but you get the idea, crazy stuff. Here is an article in Czech [0] that tells the story a bit better, but you have to translate it.
[0] https://www.root.cz/clanky/pribeh-domeny-sk-aneb-kradez-za-b...
// EDIT: I have found that the article actually links the movement to return the TLD back [1]. It also has a story tab [2], so they have something much more precise than the paraphrasing I wrote.
Funny how people are independently converging on similar patterns of "what works" here. Still feels like we're in the wild west with all these ad-hoc patterns of agent orchestration that people are coming up with.
Obligatory list of workflow engines and libraries because it's such a common need that a lot have rolled their own. [1]
[0] https://docs.dbos.dev/python/tutorials/database-connection
In short: SQLite is not all you need, unless you’re just experimenting don’t actually care about durability, in which case you also need litestream + object storage.
Right.
If you find yourself wanting things like an easy way to then introspect your SQLite database, figure out what is happening in the workflow, compose individual tasks, make workflows trivially callable, etc, give Temporal a look.
Alongside this, I have mostly moved away from files for agents. Markdown and JSON are great, but also feel like traps when building out smaller local apps. LLMs are great at SQLite and you can render anything you want out of it (Markdown, JSON, etc). It saves a lot of tokens when an agent can just query a specific row instead of having to fire up jq or grep through markdown. You get a nice portable self contained data management system that encourages agents to be more disciplined about how they structure their data than a bunch of files. It also continues to scale into MySQL/Postgres if your little local projects start to outgrow or become more formal, you already have schema and discipline around data.
I want to love it, and I don't take open source projects like this for granted. But during my last production upgrade I chose to decommission Litestream in favor of a dumber, less granular solution using sqlite3_rsync and nightly backups because there is no point in using a backup system that is not rock solid.
That's distributed workflows :)
synchronous_commit = onBy default. Generally your primary database is in a completely different failure category than a kubernetes node running an ephemeral workflow pod.
PRAGMA synchronous = full2026-05-29
DBOS recently argued that Postgres is all you need for durable execution: if you already trust your database, you do not need a separate orchestration tier. I agree with the direction, and I think the idea can be pushed further.
For a large class of durable systems, SQLite is all you need.
Durable execution is often discussed as if it requires durable infrastructure. In many cases it does not. The durable part is the workflow state. The compute can stay cheap and disposable.
That is a natural fit for Obelisk: workflow progress lives in an execution log, workflows replay from persisted history, and activities can be retried. What matters most is keeping the workflow state around and easy to inspect.
SQLite is appealing because it gives you transactional durable state without introducing a separate database service. There is no network hop, no extra control plane, and no new operational surface area just to keep workflow progress safe. For many systems, a local database file is exactly the right level of machinery.
The obvious concern is what to do with those SQLite files once experiments start to accumulate. That is where Litestream helps. It can stream SQLite changes asynchronously to S3-compatible object storage. That gives you a simple way to keep working state close to the runtime while still copying databases out for backup, migration, and inspection.
The caveat is that Litestream replication is asynchronous. A restore can miss the newest local writes if the SQLite volume disappears before they are copied. That is fine for many AI and experimentation workflows, but it is not the same thing as a highly available shared database.
That still leads to a useful operating model: run an Obelisk server with a SQLite database, back it up with Litestream, and let an observer pull interesting databases when needed. The same file can be used for local replay, debugging, and understanding what an agent actually did.
This is especially attractive for AI agents and AI-generated workflows. Those systems are often bursty, experimental, and easier to reason about when each agent or tenant has a small self-contained unit of state. A fleet of tiny servers in micro VMs or containers, each with its own SQLite database and object storage backup, is often a better fit than one large always-on shared system. It is simpler, cheaper, and gives better fault isolation.
SQLite is not the answer to every deployment shape. Obelisk also supports Postgres, and that is the right choice when you need higher availability, broader shared scalability, or other deployment properties that are better served by a network database. It is also the better fit when asynchronous replication to object storage is not the durability model you want.
Many workflow systems do not need that on day one and should not start with more infrastructure than their state actually demands.
In a large set of cases, a local SQLite database plus Litestream backup to S3 is enough. Add cheap workers around it and you get a durable system with very little infrastructure. For the world of AI agents, that may be the most sensible default.