Live data from Hacker News

Omnigres: Postgres as a Platform

github.com

51–60 of 77 posts

Re: Omnigres: Postgres as a Platform

#51

Oh wow, this is great. Congratulations Yurii. So i Tried omnigress to build a simple api that does few db calls a month back to mock real world scenario. And damn, the numbers were quite thought provoking. Comparing those numbers with a similar api built using fastapi and asyncpg, there was if i remember correctly at least 4x to 5x throughput increase. Even though the project is in quite nascent stage, the idea is pr…

> Comparing those numbers with a similar api built using fastapi and asyncpg, there was if i remember correctly at least 4x to 5x throughput increase.

I wonder to what extent this improvement comes from not using Python, as opposed to using this alternative solution? For example after Python to Go migrations it’s common to see this kind of speed up I believe.

Re: Omnigres: Postgres as a Platform

#52

At some point during the dot-com era, Microsoft toyed with adding an HTTP server to its SQL Server product to enable similar development paradigms. My recollection is that this was a disaster on several fronts, not the least of which was that successfully breaching the HTTP server gave an attacker direct access to the database. This (and other considerations) make a good case for the kind of separation-of-concerns wh…

There was a similar tool developed by Oracle called mod_plsql, which served as an Apache web server module. As far as I remember, it allowed you to configure a mapping from a URL to a stored procedure. These stored procedures could receive HTTP request parameters and return HTML content.

I've always felt that this approach is the right way to build applications. Application servers seemed like an unnecessary layer to me, essentially serving as intermediaries that merely passed data from the database to the browser. In the past, they played a more critical role in generating HTML, but nowadays, application servers are primarily used for handling APIs. Consequently, they often lack meaningful tasks to justify their existence.

Having your code closely integrated with the data also has the benefit of improving performance.

Re: Omnigres: Postgres as a Platform

#54
post #40
post #39

Love this. The problem I have with this approach, though, is SQL itself. Until we get simple things such as inserts and unions based on field name rather than field order, there are simply too many pitfalls for me.

Please elaborate because that sentence make barely no sense for modern SQL engine such as PostgreSQL. A good ressource to start exploring would be this site with compare features between vendors: https://modern-sql.com/

I believe what they’re talking about is being able to pass something like a struct of key-value pairs, which correspond to column names in the inserted table. This would let us pass straight records/maps/whatever you want to call them to the db, and have the correct insert performed, instead of the genuinely horrible string-interpolation-hope-you-got-the-right-number-of-params-in-the-right-order-and-too-bad-if-you-didn’t dance that we currently have.

The interface we have with databases could be so much better.

Re: Omnigres: Postgres as a Platform

#55

Oh wow, this is great. Congratulations Yurii. So i Tried omnigress to build a simple api that does few db calls a month back to mock real world scenario. And damn, the numbers were quite thought provoking. Comparing those numbers with a similar api built using fastapi and asyncpg, there was if i remember correctly at least 4x to 5x throughput increase. Even though the project is in quite nascent stage, the idea is pr…

> Comparing those numbers with a similar api built using fastapi and asyncpg, there was if i remember correctly at least 4x to 5x throughput increase. I wonder to what extent this improvement comes from not using Python, as opposed to using this alternative solution? For example after Python to Go migrations it’s common to see this kind of speed up I believe.

They might have used Python still - the Omnigres page lists Python support, and PG has had PL/Python for a long time.

Re: Omnigres: Postgres as a Platform

#57

At some point during the dot-com era, Microsoft toyed with adding an HTTP server to its SQL Server product to enable similar development paradigms. My recollection is that this was a disaster on several fronts, not the least of which was that successfully breaching the HTTP server gave an attacker direct access to the database. This (and other considerations) make a good case for the kind of separation-of-concerns wh…

I work at a shop that viewed MSSQL as a platform just like the OP describes. Of course noone ever pointed that out to me, but as we migrated more and more away and the graybeards became upset about moving logic out of stored procedures into the application... and async tasks out of Agent jobs into an application job server... it dawned on me.

Would not recommend this path, but that is probably because I understand deployments and platforms. if they can fix the ergonomics, modernize the process, I could see it working out.

I suppose replacing your OS with postgres could have its advantages.

Re: Omnigres: Postgres as a Platform

#59
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/...

Re: Omnigres: Postgres as a Platform

#60
post #40
post #39

Love this. The problem I have with this approach, though, is SQL itself. Until we get simple things such as inserts and unions based on field name rather than field order, there are simply too many pitfalls for me.

Please elaborate because that sentence make barely no sense for modern SQL engine such as PostgreSQL. A good ressource to start exploring would be this site with compare features between vendors: https://modern-sql.com/

I think they were talking about syntax like INSERT INTO t(a,b,c) VALUES (1,2,3)

I agree that something like INSERT INTO t VALUES a=1, b=2, c=3

would be much more readable.

Post reply on HN