bugzino
omnigres
bugzino | omnigres | |
---|---|---|
1 | 15 | |
12 | 1,274 | |
- | 3.1% | |
2.2 | 9.7 | |
about 1 year ago | 17 days ago | |
Kotlin | C | |
- | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
bugzino
-
The Database Package Manager for PostgreSQL Trusted Language Extensions
At KotlinConf today I gave a talk on designing apps with two-tier architecture, where you implement your entire app without the web stack appearing anywhere at all. Instead you publish desktop and mobile apps that connect directly to an RDBMS like PostgreSQL via its native protocol, and use server extensions for any logic that is inconvenient to do with SQL.
This approach might seem horrifyingly outside-the-box but has a lot of advantages, and some of the reasons we didn't do things this way historically have been solved in recent years.
Because it was KotlinConf the demo uses PL/Java, which is pretty nice because there's such a healthy ecosystem of stuff based around JDBC and because deploying JVM stuff doesn't require any sort of cross-compilation. PL/Java also supports (for now) trusted extensions using sandboxing, although of course the sandbox can just get in the way and normally you trust your own server anyway so this is a double edged sword.
The demo code can be found here (it's a prototype and nobody reviewed it yet so be gentle)
https://github.com/hydraulic-software/bugzino
I'll write up a blog post version of the talk, but for now I had to mention that DBaaS providers don't actually enable this sort of design because they like to wall off the full power of the RDBMS behind custom APIs. But in two-tier design you really lean into the database and use all of its features. So, it'd be nice if:
a. database.dev were to support PL/Java extensions.
b. Supabase were to allow direct connections, as the native DB protocol supports a lot of features that otherwise have to be sort of hacked on top of HTTP. Ultimately, HTTP is designed to fetch hypertext whereas the PG native protocol is designed to work with data, and that difference shines through in a bunch of ways.
omnigres
-
Building a Managed Postgres Service in Rust
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
-
PostgREST: Providing HTML Content Using Htmx
If you think that's cool, you might also want to check out Omnigres:
https://github.com/omnigres/omnigres
-
Ask HN: Who is hiring? (December 2023)
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]
-
Ask HN: Who's looking for contributors for OSS Projects
Check out Omnigres: https://github.com/omnigres/omnigres/wiki/Bounties
They just launched a bounty program recently.
-
Ask HN: Who is hiring? (November 2023)
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
- Show HN: Pg_yregress, Structured Testing for Postgres
-
Omnigres: Postgres as a Platform
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/...
-
The Database Package Manager for PostgreSQL Trusted Language Extensions
Very much in the same vein: https://github.com/omnigres/omnigres
What are some alternatives?
supavisor - A cloud-native, multi-tenant Postgres connection pooler.
hyperdx - Resolve production issues, fast. An open source observability platform unifying session replays, logs, metrics, traces and errors powered by Clickhouse and OpenTelemetry.
pgress - Native PostgreSQL JavaScript client library for web browsers
pg_tle - Framework for building trusted language extensions for PostgreSQL
set_user - PostgreSQL extension allowing privilege escalation with enhanced logging and control
langfuse - 🪢 Open source LLM engineering platform: Observability, metrics, evals, prompt management, playground, datasets. Integrates with LlamaIndex, Langchain, OpenAI SDK, LiteLLM, and more. 🍊YC W23
examples - Your one-stop-shop to try Xata out. From packages to apps, whatever you need to get started.
langchain - 🦜🔗 Build context-aware reasoning applications
pgjwt - PostgreSQL implementation of JWT (JSON Web Tokens)