TLDR: Because of serverless, the need for database wrapper api's like PostgREST have become mainstay. Supabase allows RPC postgres function calls which can house more complex "database logic" eliminating the need for an in-app model. Omnigres is a project aiming to take this concept one step further with including an HTTP server within postgres itself. I also was writing a bunch of pg functions this week which is why I noticed this trend.
There's a new way of thinking about databases / apps that's slowly morphing the way people think and opening developers up to new possibilities and ways of building apps. There's something brewing because i've been having this idea and I'm also seeing others have it as well.
The idea overall is to set postgres as the main "backend api". That we shouldn't really ever need to bundle multiple queries into a transaction in a different programming language or server at all.
To be honest i've fallen in love with Supabase. This post is not sponsored by them in any way. I just really love the product, and for me, as a champion of self-hosting and open source that's saying a lot. I believe that everyone should have their own personal database / api and "own their own data" and Supabase aids in that mission. I really love that they also have a storage solution so all your data (like a blog post and images) can live truly live one place.
There's two ways to use Supabase through the API they provide, or directly with any postgres client. If you wanted to run postgres queries directly you can, but if you wanted some of their out-of-the-box features like auth and signup flow, you can use that too. It's a real swiss-army knife. What I find really interesting is something they provide called Supabase RPC which allow you to call a custom postgres function from the supabase client. Calling functions directly can minimise the mount of vendor-lockin you have with supabase because if you use their api client, you can't make queries directly and so you'd have to make a model system using their library which is proprietary. This whole mess is made complicated and necessary when it comes to serverless hosting, which requires the need for an API rather then a direct postgres connection.
So while I was brewing about all these ideas I've been thinking of designing a slew of postgres functions that would act somewhat as "the api" i'd write the to my postgres database and call those functions rather than a traditional model, things like pagination, joins, merging, user data etc, any data massaging you'd normally do within your app.
Then the other day while scrolling hacker news this came up:
Omnigres makes Postgres a developer-first application platform. You can deploy a single database instance and it can host your entire application, scaling as needed.
- Running application logic inside or next to the database instance
- Deployment provisioning (Git, containers, etc.)
- Database instance serves HTTP, WebSocket and other protocols
- In-memory and volatile on-disk caching
- Routine application building blocks (authentication, authorization, payments, etc.)
- Database-modeled application logic via reactive queries
- Automagic remote APIs and form handling
- Live data updates
Blogs and Publications
🏃 Quick start
The fastest way to try Omnigres out is by using its container image:
docker volume create omnigres
docker run --name omnigres --mount source=omnigres,target=/var/lib/postgresql/data \
-p 127.0.0.1:5432:5432 -p 127.0.0.1:8080:8080 --rm ghcr.io/omnigres/omnigres:latest
# Now you can connect to it:
psql -h localhost -p 5432 -U omnigres omnigres # password is `omnigres`
Postgres parameters such as database…
omnigres is "Postgres as a platform" that takes all of this one step further.
Omnigres makes Postgres a developer-first application platform. You can deploy a single database instance and it can host your entire application, scaling as needed.
What's interesting is I had started working on a whole bunch of json function for postgres the same week I found omnigres on HN. Take a look at my progress here:
reggi
/
pg_json_functions
A collection of Postgres functions designed to work with supabase's RPC calls.
What do I hope to achive?
I've been tinkering around with different ideas when it comes to the idea of having structured data in the database without the need to utilize the typical relational-table based (normal) way you'd use postgres.
I've been messing around with things like yunohost.org, my own personal json API for blog posts, and other forms of structured content using strapi.io (a headless cms that utilizes postgres). The state of self-hosted software has deviated slightly from my vision of a simple easy to use utopia. On one side of the spectrum is yunohost.org, which offers a way to have a single server "install" other third-party self-hosted apps and using complex nginx rules route request to running ports all on the same machine, which is resource intensive, for each "app" running on the same box more ram, cpu, and storage is needed if you want to…
It's a bunch of functions that make it slightly easier to interact with jsonb columns, and it's mostly me tinkering around with functions and trying to learn the syntax with ChatGPT.
Anyway, that's all I got for this post. I do think there's a shift in how people are thinking about what a database should be and should do. Mainly because at some point in the 'serverless' architecture there needs to be a single server (or cluster of servers) to manage database connections, and what we ask of that server might change over time.
Top comments (0)