pgrx VS omnigres

Consider also the companies and work behind pgrx [0] and pgzx [1]:

[0] https://github.com/pgcentralfoundation/pgrx

[1] https://github.com/xataio/pgzx

If you like this (I do very much), you might also like pg_idkit[0] which is a little extension with a bunch of other kinds of IDs that you can generate inside PG, thanks to the seriously awesome pgrx[1] and Rust.

[0]: https://github.com/VADOSWARE/pg_idkit

[1]: https://github.com/pgcentralfoundation/pgrx

(disclosure, i work at supabase and have been developing TLEs with the RDS team)

Trusted Language Extensions refer to an extension written in any trusted language. In this case Rust, but it also includes: plpgsql, plv8, etc. See [0]

> PL/Rust is a more performant and more feature-rich alternative to PL/pgSQL

This is only partially true. plpgsql has bindings to low-level Postgres APIs, so in some cases it is just as fast (or faster) than Rust.

> Building a vector index (or any index for that matter) inside Postgres is a more involved process and can not be done via the UDF interface, be it Rust, C or PL/pgSQL

Most PG Rust extensions are written with the excellent pgrx framework [1]. While it doesn't have index bindings right now, I can certainly imagine a future where this is possible[2].

All that said - I think there are a lot of hoops to jump through right now and I doubt it's worth it for the Latern team. I think they are right to focus on developing a separate C extension

[0] TLE: https://supabase.com/blog/pg-tle

[1] pgrx: https://github.com/pgcentralfoundation/pgrx

[2] https://github.com/pgcentralfoundation/pgrx/issues/190#issue...

I’m currently playing with PostgreSQL, foreign data wrappers, and pgrx rust extensions. My development experience has been surprisingly smooth and enjoyable.

My main issue is that joins will be processed locally, so all the foreign data will be fetched before the join happens. But otherwise basic CRUD is easy.

https://wiki.postgresql.org/wiki/Foreign_data_wrappers

https://github.com/pgcentralfoundation/pgrx

https://github.com/supabase/wrappers

I think maybe what you’re really looking for are the files here: https://github.com/pgcentralfoundation/pgrx/tree/c2eac033856...

Those are the internals we currently expose as unsafe “sys” bindings.

As we/contributors identify more that are desired we add them.

pgrx’ focus is on providing safe wrappers and general interfaces to the Postgres internals, which is the bulk of our work and is what will take many years.

As unsafe bindings go, we could just expose everything, and likely eventually will. There’s just some practical management concerns around doing that without a better namespace organization —- something we’ve been working.

The Postgres sources are not small. They are very complex, inconsistent in places, and often follow patterns that are specific to Postgres and not easy to generalize.

If you’ve never built an extension with pgrx, give it a shot one afternoon. It’s very exciting to see your own code running in your database.

pgrx is one of the greatest enabling innovations in the PG ecosystem in a long time.

Awesome to see so many high quality extensions come out of it.

https://github.com/pgcentralfoundation/pgrx

If you're interested in what my Threadripper 3970X does with it, there's some numbers in this PR: https://github.com/tcdi/pgrx/pull/1147

I've been writing Postgres extensions for a few years now (mostly in C and Python), and I have to say that an important contribution from companies like Tembo and Omnigres is in the area of tooling and boilerplate. From workflows to Dockerfiles [0], that's important for the future of Postgres.

This has been discussed in the past [1], but the Postgres tooling ecosystem has been primarily C-Makefile—mailing list driven, and there used to be a lot of Makefile targets copy-pasting. Whenever major Postgres providers wanted to open source some of their extensions / sub-products. I still feel, however, that a lot of Postgres C-know-how is being slowly forgotten / lost, and I think it will be necessary again soon. Internal things as how Postgres handles varlena, StringInfo, JsonbValue, etc. The core abstractions that make Postgres work.

0: https://github.com/omnigres/omnigres/blob/master/Dockerfile

If you think that's cool, you might also want to check out Omnigres:

https://github.com/omnigres/omnigres

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.

Email: [email protected]

Check out Omnigres: https://github.com/omnigres/omnigres/wiki/Bounties

They just launched a bounty program recently.

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

Couple of questions (with notes): Yes, I'd really like to write code next to the db with more suitable (for task) languages like Python. But at the moment SQL alone is supported..? Could one connect with Jupyter notebook somehow and have a REPL like experience with Omnigres instance?

Also, this [1] seems intriguing. How do containers connect to the db? What would the performance differences to the "internal" approach? Is this feature more like Lambda or for long running processes? Or something else? In any case very interesting.

Thank you!

[1] https://github.com/omnigres/omnigres/tree/master/extensions/...

Very much in the same vein: https://github.com/omnigres/omnigres