yrashk

I've been working on some parts of this problem, specifically capturing and retaining other semantically useful layers of the systems we build as we build and maintain them.

By introducing progressive semantically enriching layers (starting with prose, reasoning and terminology and going all the way into specifying interaction surfaces), we can reduce the dark matter between spec and code, make code more disposable – if your semantics live in the spec layer rather than the implementation, you can throw away and regenerate the implementation without losing understanding – and, critically, give LLMs a way to navigate a graph of knowledge instead of gobbling up walls of text.

https://clayers.com -- https://github.com/CognitiveLayers/clayers

Relax NG Compact is a great way to communicate schemas to LLMs in a token-efficient way.

This document describes the conceptual architecture of our company workspace - a text-based, version-controlled knowledge and operations hub designed to replace tools like Notion and Webflow while being natively accessible to AI assistants.

This happened to FerretDB

seemingly only for domestic R&D

As an international founder, I'd like the section 174 to be fully restored as it was before – not just for domestic R&D but offshore one as well, so we're not hit with 15 years deprecitation (it is as good as "infinity")

I also own section174.com and sec174.com

Would these help with visibility?

This is the first _published_ version: https://docs.omnigres.org/omni_txn/linearize/

Please bear in mind that it's not a final version yet – it is a snapshot from a PR.

Few more cases are being worked on!

The article describes a technique type-safe joins in Postgres.

Current image builds are to be phased out soon(ish). They were a way to get something into people's hands. And yes, plrust/rust are definitely space hogs :)

I've been a user since the early days and loved the immediacy of responses to all our issues. Issues were fixed nearly instantaneously. It's very impressive.

Yet to explore the new capabilities!

As somebody who writes a lot of Postgres extensions, I can say this is quite interesting!

I think I can see some parallels to Supabase's wrappers project.

Keep up the good work!

Omnigres | Founding Engineer | SF Bay Area HQ | REMOTE

At Omnigres, our north star is to enable developers to laser-focus on business needs instead of fighting technological challenges.

We're fighting the complexity and inefficiencies of contemporary stacks by removing them instead of hiding them.

At the core, we are turning Postgres into an Application Runtime. Why? Because we believe that code and data are inseparable in pretty much all of the line-of-business application systems. Turns out, when done this way, applications work a lot faster, require a lot less maintenance and are simply easier to write.

Our foundation is open source and is available at https://github.com/omnigres/omnigres

We're backed by some great early-stage VCs and looking to onboard people who can move quickly, learn on the go and maintain the focus on the goals. Another way to look at it: we want to meet other pragmatic idealists.

You can apply here https://wellfound.com/jobs/2832133-founding-engineer or email founders@omnigres.com

We are primarily talking about the backend side of this story at this time.

We'll see what the future will bring, as the real edge of computing is in user's hands.

There's a keen interest to get there for Omnigres applications, but the shape of that is still somewhat vague.

We're experimenting with JSC.

It does not have any UI yet. Something we haven't thought much about yet. Technically, feasible, just need to have a good story to drive a good experience there.

Currently, we have an early version of `omni_schema` [1] that allows traditional incremental migrations and in-place migration of certain objects.

However, we're not quite satisfied with this and working on a more sophisticated system that would allow us to derive incremental changes where possible, lint schema, load application code with the right dependencies on types and other functions where necessary.

[1] https://docs.omnigres.org/omni_schema/reference/

We are working on first-class support for Python indeed (and other languages like JavaScript)

An important thing here is that we see Omnigres as a polyglot runtime with a database inside (Postgres) and we want people to use languages they prefer.

In my tests, I was testing against Node.js and Rust and was getting roughly the same numbers.

https://yrashk.com/blog/2023/02/16/what-happens-if-you-put-h...

In the instance of short-living queries, we are able to get this by effectively removing the communication latency.

Interestingly enough, I've toyed with augmenting SQL to make it more useful.

I remember doing an experimental improvement allowing to do FROM where SELECT what syntax.

I agree there's value there. Omnigres is able to intercept query expressions to do the augmentation.

That's right. This is on our near-term roadmap at Omnigres.

You can use any language Postgres supports or will support to write your logic.

We are adding first-class Python support right now. It's already possible to extrsct stored functions from decorated functions and their type hunts and we're working on providing standard Python APIs like DBAPI, WSGI support, etc. We have a branch on which we ran Flask applications inside Postgres. As it matures, it will be merged and documented.

As for the containers, they receive the database credentials over env variables currently. The performance characteristics of such applications aren't as good currently. The intended use case for this is third-party apps and legacy pieces of own applications.

Please keep in mind that this extension hasn't received much updates in the past couple of months but there will be upcoming changes to simplify ot a lot and provide more functionality. We also have a future experimental goal of going all the way through a runtime like crun to remove moving pieces.

Thanks! I am pleasantly surprised my name rings the bell for some :)

We're actually first-classing a number of languages and ecosystem support precisely so that people can use their languages of choice and not just SQL or Pl/pgSQL.

Thank you for posting Omnigres on HN!

Just a quick note to the readers: we're still in the early days, in a pre-release mode. A lot of things work, but not everything is there yet and there are some bugs (we know some for sure!). A lot to come as we progress: first-class Python support, CLI, schema & package management, etc.

Our initial users are using it with our support and our timeline is sometimes advised by their milestones.

That said, happy to see you try it out and please join our Discord (https://discord.omnigr.es/) if you want to chat.

Actually, some of the feedback that we received from fairly close to the source, was that Postgres as an application platform of a sort was the original vision for it.

But I can see how this work can be perceived through your lense.

It's not currently spelled out in the readme, but our approach does lend for straightforward shipping of complete systems (data + code) to the edge because it's effectively just a replication of the database. We're working on further primitives that facilitate such an operational model.

We believe that a practical edge [backend] requires the presence of data next to the code, which is precisely what Omnigres promotes.

We don't really use connections but a pool of workers to process requests.

Having http server tightly coupled with the database server makes for a responsive combo.

We are still blocking workers, but prototyping improvements that will alleviate this.

I am aware of kdb, J and others in the space! Love their brevity and ingenuity.

As you rightly point out, the idea behind Omnigres is to make a lot of these concepts available broadly.

Thank you for your kind words! The original dream was indeed a "one box" approach, even when they scale horizontally and to the edge. Perhaps a more accurate depiction of this is a "unified interface".