Forem: Omnigres

Firing Developers Won’t Make Software Cheaper

Yurii Rashkovskii — Tue, 08 Jul 2025 17:31:22 +0000

Everyone cheering AI coding tools says the quiet part out loud eventually:

“So… when can I fire my developers?”

That’s the real subtext no one puts in their blog posts.

“A new class of builders is emerging” → (Translation: maybe we don’t need expensive engineers?)
“Focus on outcomes, not methods” → (Translation: maybe we don’t need people who care about methods?)

Under the polished veneer of empowerment, the motivation is clear: cut costs, move faster. And there’s nothing inherently wrong with that.

Except we’re focusing on the visible output of software developers, and confusing that with their value. Simulating the output doesn’t eliminate the role — it just replaces developers with something fast, unpredictable, and equally expensive in other ways.

You're still left with messy, brittle, over-complicated systems – just built faster and broken differently.

The real move isn’t to replace developers with AI.

It’s to stop needing so much software engineering, operations, and maintenance in the first place.

The Fantasy of Fewer Engineers

Every few years, a new wave of tooling arrives that promises to make engineers obsolete. Even in the early days. COBOL. 4GLs. Visual Basic. No-code. Now, AI.

Each time, the hope is the same: let someone else (or something else) do the building. But the underlying complexity doesn’t go away. It just gets hidden. Until it leaks.

AI today is like hiring a half-drunk junior developer: fast, tireless, and unaware of consequences. It can spit out working code, but it can’t reason about tradeoffs, edge cases, evolving requirements, or failure modes.

Software isn't expensive because of syntax. It's expensive because systems live for years, not minutes.

The Problem Isn’t Developers. It’s Over-Engineering
If you're trying to build business systems cheaper, the goal shouldn't be firing developers.

The goal should be to need less bespoke code in the first place.

Too many products are weighed down by:

Separation of concerns
Over-abundant, over-dependent microservices
Ongoing maintenance and migration tax

We've been chasing clever architectures instead of asking whether we need this much architecture.

Data, Not Software, Is the Core of Business Systems

That’s what I’m working on.

Since 2004, for over 20 years, I haven’t been able to shake the belief that the real heart of most business systems isn’t the code.

It’s the data.

Business workflows are usually just data state machines: records moving through stages, reacting to events, triggering outcomes.

But data has been:

Misunderstood by app developers
Constrained by layers of abstractions
Boxed away in the realm of DBAs and managed services

What if we stopped pushing data to the edges of the system? What if we started with data and let systems emerge from there?

The Future: Data-Native Architectures

Not AI-generated code. Not yet another abstraction layer. But a fundamental shift in how we model, build, and reason about systems.

If we want cheaper, more maintainable business software, we need to stop repeating the cycle: new tool, same mess, slightly better.

We must reduce the need for software and understand that data is not buckets of "things" but a structured and fluid representation of reality.

Let’s stop asking, "When can I fire my developers?"

Let’s ask, "What can we build so we don’t need as many developers in the first place?"

Let’s stop hiding the complexity.

Let’s eliminate it.

What happens if you put HTTP server inside Postgres?

Yurii Rashkovskii — Mon, 06 Feb 2023 15:53:36 +0000

Cover photo by Clark Tibbs on Unsplash

Benchmarks and performance claims are attention-grabbers, but that's not what drew me to work on Omnigres. When I first built a prototype of its HTTP server, I didn't foresee the desire to share the numbers. As we all know, getting benchmarks right is hard, and everybody's mileage may vary. But I'll show you some numbers here anyway. It'll be great to validate or invalidate my findings!

But first, what's Omnigres? The shortest definition I came up with is "Postgres as a Platform."

What do I mean by this? Well, this comes from the idea that much of your application and its infrastructure can live inside or next to Postgres. Your business logic, deployment orchestration, caching, job queues, API endpoints, form handlers, HTTP server, you name it. Instead of building a system composed of multiple services, you only need one server that takes care of it. And if it can scale, you've got something great!

I am not the only one intrigued by this idea (and many don't like it, either): check out this HN thread.

And it is not "one-size-fits-all." But it fits a good set of problems. Anyway, that's a subject for another conversation.

In the past weeks, I've taken the task of adding an embedded HTTP server to Omnigres. Since Omnigres is implemented in C , it was only natural for me to choose libh2o to implement the functionality of an HTTP server. It did help that H2O is known for its good performance characteristics.

The idea was relatively simple: initialize a few HTTP worker processes, each quickly handing off details of the incoming HTTP requests to a Postgres instance in the same process.

Sounds a bit weird, right? But bear with me, I will try to explain what's going on.

Below is a sample piece of code of how an HTTP request can be handled.

SELECT omni_httpd.http_response(headers => array[omni_httpd.http_header('content-type', 'text/html')], body => 'Hello, <b>' || users.name || '</b>!'), 1 AS priority
       FROM request
       INNER JOIN users ON string_to_array(request.path,'/', '') = array[NULL, 'users', users.handle]
UNION
SELECT omni_httpd.http_response(status => 404, body => json_build_object('method', request.method, 'path', request.path, 'query_string', request.query_string)), 0 AS priority
       FROM request
ORDER BY priority DESC

The first query in the union joins the request path of /users/:user with the users table on users.handle column and serves an HTML response with that user's name.

The second query, being lower in priority, simply returns a 404 Not Found response with a JSON that contains some of the request details.

$ http POST localhost:9000/users/johndoe
HTTP/1.1 200 OK
Connection: keep-alive
Server: omni_httpd-0.1
content-type: text/html
transfer-encoding: chunked

Hello, <b>John</b>!

$ http POST localhost:9000/test\?q
HTTP/1.1 404 OK
Connection: keep-alive
Server: omni_httpd-0.1
content-type: text/json
transfer-encoding: chunked

{
    "method": "POST",
    "path": "/test",
    "query_string": "q"
}

Once all this worked, I decided to try benchmark it (mostly because I wanted to see how bad would it be):

$ wrk http://localhost:9000/users/johndoe -c 20 -t 10
Running 10s test @ http://localhost:9000/users/johndoe
  10 threads and 20 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   354.85us    1.40ms  47.24ms   97.05%
    Req/Sec    12.51k     2.37k   25.01k    73.84%
  1256199 requests in 10.10s, 179.70MB read
Requests/sec: 124366.73
Transfer/sec:     17.79MB

That's on MacBook Pro M1 Max. I've also ran the same test on an older x86_64-based Linux machine and got about 70K/sec.

For reference, I decided to try comparing this with a similar (but quick-and-dirty-written) Node.js implementation that goes to the database for the same effect:

const http = require("http");

const { Pool } = require('pg')

const pool = new Pool({ /* connection details */, max: 10, idleTimeMillis: 1000 * 60});

const host = 'localhost';
const port = 8000;
const requestListener = function (req, res) {
    const split = req.url.split('/');
    if (split.length == 3 && split[1] == 'users') {
      pool.query({name: "q", text: "SELECT users.name FROM users WHERE users.handle = $1", values: [split[2]]}).
        then((qres) => {
          if (qres.rows.length == 1) {
            res.setHeader("Content-Type", "text/html");
            res.writeHead(200);
            res.end(`Hello, <b>${qres.rows[0].name}</b>!`);
          } else {
            res.setHeader("Content-Type", "application/json");
            res.writeHead(200);
            res.end(JSON.stringify({method: req.method, path: req.url}));
          }
        })
    } else {
      res.setHeader("Content-Type", "application/json");
      res.writeHead(200);
      res.end(JSON.stringify({method: req.method, path: req.url}));
    }
};
const server = http.createServer(requestListener);
server.listen(port, host, () => {
    console.log(`Server is running on http://${host}:${port}`);
});

And I re-ran the test:

$ wrk http://localhost:8000/users/johndoe -c 20 -t 10
Running 10s test @ http://localhost:8000/users/johndoe
  10 threads and 20 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.11ms    0.99ms  33.09ms   99.15%
    Req/Sec     1.89k   166.30     2.19k    92.18%
  190319 requests in 10.10s, 33.76MB read
Requests/sec:  18838.56
Transfer/sec:      3.34MB

From the surface, it looks like omni_httpd is faster for the time being! I am sure with time it'll get slower and I did not explore enough optimizations available for the Node.js experiment (please contribute to make this picture fairer!). But it shows what bundling can do to performance!

Update: As someone pointed out, using TCP locally brings unnecessary overhead where UNIX sockets would have performed better. So, I re-ran the Node.js test over UNIX sockets:

$ wrk http://localhost:8000/users/johndoe -c 20 -t 10
Running 10s test @ http://localhost:8000/users/johndoe
  10 threads and 20 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   663.15us  224.77us   9.87ms   93.24%
    Req/Sec     3.05k   139.17     3.30k    88.71%
  306649 requests in 10.10s, 54.39MB read
Requests/sec:  30361.88
Transfer/sec:      5.39MB

It's indeed quite a bit faster but still way below the numbers I was able to get with omni_httpd.

I want to emphasize that performance was not and is not a primary goal behind this work. What I think is more important there is changing the way we think about serving HTTP clients, doing data-aware routing, etc. There's still a lot of research to be done on this end.

I also want to mention that this is still early work. There's a lot to be done to make this server production-grade (starting from enabling HTTPS support, and improving the architecture to make HTTP2 multiplexing really work, but not ending there), as well as building out other extensions to make building applications really easy and convenient.

If you want to chat more, join us on Discord or Telegram!

Why not Rust for Omnigres?

Yurii Rashkovskii — Fri, 06 Jan 2023 17:19:09 +0000

Omnigres is a new project to turn Postgres into a complete development and production deployment platform. I've started it to reflect on the complexity and inefficiencies plaguing modern business software development.

As an aging (and sometimes cranky!) developer, I crave simplicity. But that's a topic for another post. Here I wanted to address a common question:

Why didn't you implement this in Rust?

It's a great question, considering I've been using Rust for a number of years now, and I generally advocate its use for its rich ecosystem, safety and tooling. I actively contribute to pgx, a library for building Postgres extensions in Rust. Yet, Omnigres appears to be all done in C.

Here's why.

Beware: the list has a lot of subjective and controversial opinions.

Making a good wrapper (pgx) is a lot of work

While it's getting there, when you try to build something pushing the boundaries, pgx may not yet provide sufficient API coverage, so you have to resort to unsafe FFI. It drove me to make a number of contributions to it. Still, since it takes a while to refine them enough to be considered well-rounded, it impedes general development velocity.

Making a good, safe wrapper for such a complex project as Postgres is a significant undertaking. It'll take however long it takes. That's why I am wholeheartedly supporting it and spending time evolving it.

But as of today, I want to be able to move fast.

Postgres is [quirky] C

Its whole internal API is designed to be consumed by C code, and Postgres doesn't know anything about your other language.

It uses setjmp/longjmp for exceptions (so you'd have to roll your own guards to unwind the stack). It has its own memory management system. It manages the SPI stack. It has lots of mutable global variables!

So, to consume it from C is only natural, even though it can be dangerous.

Dependencies

Between not really knowing what's inside of your dependencies and obnoxious compile times, there's a reason for having less dependencies.

Rust's Cargo makes it terribly easy to add dependencies, so there's no tax on adding yet another library. This is generally seen as a good thing in the industry, but I keep coming back to the idea that less is better.

If, however, you had to pay for every dependency, we'd use a lot less of them, only when necessary. C is excellent in this department! I gave up on a number of dependencies simply because I had difficulties integrating them into my build system. So I see this is a filter for the need and the quality of the dependency.

Fast compile times

Rust compiler is notoriously slow. Pgx brings its own complexity that makes rapid iteration nearly impossible. My builds are extremely fast with C. It's a simple language, and I tend to add very few dependencies.

Complex language fatigue

I've been developing software for a few decades now and am growing tired of complex languages. Going back to C feels like taking a vacation and stopping chasing ideals and just focusing on the problem at hand.

If Postgres (or Linux kernel) can be done in C, I am sure a few extensions could, too!

Formal verification methods

There are projects that are focusing on bringing this to Rust, but there are some great static analysis and formal verification tools that have been used in C for quite a while. I fancy Frama-C and try to add it bit by bit to Omnigres where I think it may be necessary.

Rust safeties are slightly less relevant in Postgres

Postgres is inherently single-threaded and therefore, "fearless concurrency" is not buying us much. Sure, you can build an extension that'll communicate with other processes and threads over shared memory, but this is not much of a concern at the core database level.

Postgres has its own memory management story, which is quite good. Instead of having a single allocation pool, it has memory contexts that are established temporarily or for a scope. When they are deleted, all the memory allocated in them is released. So memory leaks are not necessarily a concern. Rust doesn't necessarily consider leaks a safety issue, but it's nice to know we will not crash the server with an OOM.

Of course, there's still use-after-free, which you have to be careful about. This is where tools like AddressSanitizer can come in very handy.

I've seen that most of my crashes in the extensions were coming from misusing some Postgres API, and I was getting a lot of them in Rust as well.

But Yurii, isn't C a dangerous and flawed language?

Yes, it is both dangerous and flawed. In general, I wouldn't build new projects in C, but after months of going back on forth on this, I think, ultimately, building a project on top of Postgres in C is reasonable.

Did you consider Zig?

I absolutely did. I am very interested in Zig (and have previously developed some small projects in it) and I keep track of its development. But I ultimately didn't want to fight both Postgres and Zig at the same time.

Did you consider Nim?

You bet! The attraction was that it compiles to C, and I can emit C code where necessary, obliterating the need to replicate certain tricks. But it's a complex, big language, and I am not confident about its own bugs, obscurities and upgrade stories (Nim 2 is coming!)

Knowing how Rust crowd behaves sometimes, there may be those inclined to persuade me to change my opinion or prove me wrong. Of course, they are free to do so, but I'd prefer to focus on getting things done!

Ultimately, I think Rust is great. Omnigres will have first-class support for it and will promote its use and the use of pgx for building extensions.