Local open weight models will definitely be a future trend. Imagine if an Opus-level model could run locally: many more latent use cases would likely emerge, since Opus is priced so high. Perhaps the future will be a multi-model architecture, where frontier models handle planning and local models carry out the concrete execution.
I’ve been building pie, an open-source coding agent written in Rust. The initial reason was that I had some proactive, long-term automated tasks to run on a local DS v4 model. Therefore, I needed a customizable agent runtime to support these custom tasks, such as triggers, to perform some simple automation, Over time, the project gradually became more and more usable, so I thought I might as well turn it into a proper project.
Of course, most of the code in this project was written by AI. If you’re sensitive to AI-generated code or AI coding, feel free to simply ignore it.
Pie runs inside your local project directory, can inspect/edit files, run shell commands, keep resumable sessions, and use different model providers, including local OpenAI-compatible servers.
The goal is not just to build another chat UI for coding, but a local agent runtime for developer workflows: slash commands, session history, skills, MCP tools, cron/triggers, and a small hub so agents running on different machines can send messages to each other.
A few things I’ve been focusing on recently:
- local/session-first workflows: resume sessions, search history, save transcripts
- model flexibility: Anthropic/OpenAI/etc., plus local OpenAI-compatible endpoints
- MCP and skills for attaching project-specific tools/instructions
- cron/triggers for lightweight automation inside a coding session
- SSH/headless support for running agents on remote dev boxes
- a web UI that mirrors the terminal runtime rather than replacing it
- an optional hub for agent-to-agent messaging and notifications
Hello, the developer of db9 here. You’re right, that section is indeed a bit too brief. We will add more architecture documentation later.
What I wanted to convey is that, unlike a standard PostgreSQL, db9 is more like a pg SQL-compatible layer built on top of a large distributed KV store.
I also shared a brief introduction in this tweet, which might help clarify things. https://x.com/dxhuang/status/2032016443114733744
"Compatible" isn't mentioned on the homepage, though, despite multiple opportunities to do so -- "Create, manage and query serverless PostgreSQL", "Run history, status, and metadata live in Postgres", "Full Postgres. Fully typed.".
This lack of detail may cause folks to form the incorrect impression that this is PostgreSQL, or a fork of it, or some module or plugin for it. Folks will be upset to learn that they were misinformed. Some will assign deception as the cause, whether that is true or not.
I think your interests would be best served by trying to make that distinction clear and prominently so. So for example "A PostgreSQL-compatible, fully serverless database", or similar.
it has nothing to do with TiDB, db9 is built from scratch.A good way to think about it is that db9 is similar to tidb-server, it provides a PostgreSQL wire protocol and SQL layer, while the actual data lives in the underlying KV layer.
If it is based on TiKV, why is it built from scratch when TiDB exists? To achieve faster boot times? I think the bigger offering here is distributed-, not serverless Postgres!
In large-scale metadata scenarios, JFS recommends using a distributed key-value store to host metadata, such as TiKV or FoundationDB. Based on my experience with large JFS users, most of them choose TiKV.
I mean, planetscale first was a consumer / it looked as if they were B2C and I think they then pivoted into B2B, got postgres working, and now they are re-entering B2C-ish with the 5$ plan.
