I have an array of ideas for Omnigres, besides this HTTP component.
For example, I’m working on an embedded git client so that schema, files, templates and functions can be deployed transactionally. Or an improved binary object/streaming extension to enable better replication, external uploads, etc.
Ultimately, the goal is to make Postgres a very capable application platform.
I’m hoping to prepare a good overview of the overall picture so it’s easier to show the longer term vision.
Database connections can use all kinds of underlying protocols. If you’re colocated with your database, you can often get decent latency improvements just by switching from a TCP to a Unix Socket.
My comment was more inline with if it adds too much overhead and most spec of HTTP is not useful for a database. Like, how would a database use headers?
This HTTP-to-database connection method does not translate HTTP requests into database requests. Instead, it allows handling HTTP requests however you want (using SQL or stored procedures) from within the database, just like a normal backend would, with the benefit of being colocated with the data and its processing.
This is a very valid point. I re-ran the same test as in the article but over UNIX socket, it’s now showing about 30K req/sec (as opposed to 18K req/sec going through TCP) vs 120K+ req/sec when done within Postgres (using omni_httpd)
Because Postgres allows you to jam a lot of different programming languages into it (including compiled languages), once Omnigres has the ability to run handlers using arbitrary trigger functions, this could be quite a practical solution.
I don’t think that’s a fair description of OpenResty. OpenResty is just Nginx with a couple of modules to talk directly to databases without a middleman, and the ability to run Lua scripts. It’s not even that many components: https://openresty.org/en/components.html
Redbean is cool and there are definitely some similarities in terms of general goals and reducing complexity of development and deployment.
Omnigres is further focusing on data-centricity of majority of typical applications and is leveraging capabilities of Postgres (native extensions, replication, extensible type system, multi-language programming, foreign data wrappers, etc.) to create a one-stop-shop application platform.
Rather bonkers idea. I wholeheartedly approve.
Wait until you’ll be able to see more :)
I have an array of ideas for Omnigres, besides this HTTP component.
For example, I’m working on an embedded git client so that schema, files, templates and functions can be deployed transactionally. Or an improved binary object/streaming extension to enable better replication, external uploads, etc.
Ultimately, the goal is to make Postgres a very capable application platform.
I’m hoping to prepare a good overview of the overall picture so it’s easier to show the longer term vision.
Aren’t databases at TCP level? It would take a lot to just put an HTTP server on top of that and the cumulative overhead.
Database connections can use all kinds of underlying protocols. If you’re colocated with your database, you can often get decent latency improvements just by switching from a TCP to a Unix Socket.
My comment was more inline with if it adds too much overhead and most spec of HTTP is not useful for a database. Like, how would a database use headers?
This HTTP-to-database connection method does not translate HTTP requests into database requests. Instead, it allows handling HTTP requests however you want (using SQL or stored procedures) from within the database, just like a normal backend would, with the benefit of being colocated with the data and its processing.
This is a very valid point. I re-ran the same test as in the article but over UNIX socket, it’s now showing about 30K req/sec (as opposed to 18K req/sec going through TCP) vs 120K+ req/sec when done within Postgres (using omni_httpd)
Probably a more fair comparison would be with openresty, another attempt to jam as much as possible into one process. Update: Or even Redbean https://github.com/pkulchenko/fullmoon#what-redbean-provides
Because Postgres allows you to jam a lot of different programming languages into it (including compiled languages), once Omnigres has the ability to run handlers using arbitrary trigger functions, this could be quite a practical solution.
I don’t think that’s a fair description of OpenResty. OpenResty is just Nginx with a couple of modules to talk directly to databases without a middleman, and the ability to run Lua scripts. It’s not even that many components: https://openresty.org/en/components.html
Redbean is cool and there are definitely some similarities in terms of general goals and reducing complexity of development and deployment.
Omnigres is further focusing on data-centricity of majority of typical applications and is leveraging capabilities of Postgres (native extensions, replication, extensible type system, multi-language programming, foreign data wrappers, etc.) to create a one-stop-shop application platform.