Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Omnigres: Postgres as a Platform

github.com

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Omnigres: Postgres as a Platform

#31

Post by ako »

axelthegerman wrote: post #21
rtpg wrote: post #14

This sort of stuff (and a lot of other popular things) highlights something that I've felt for years: we are still so far away from a good ops story as an industry. Why would someone use this? Because they only want to deal with "one thing" in production. Dealing with multiple stacks is annoying. People show stuff like kubernetes as a way to handle multiple stacks. That stuff is also complicated. There is still a hug…

I hear you about the need for simplistic hosting. However I doubt shoving everything into the DB will get us there - besides some hardcore PG enthusiasts like OP & co. Sqlite together with the application layer of your choice seems to make much more sense to me, but hey we don't have to all like the same stuff (better we don't). Also without reading too much in detail but I wonder how testing/monitoring etc would be…

Why do you think shoving everything into a DB will not get us there. What about a scalable database platform like snowflake?

Re: Omnigres: Postgres as a Platform

#32

Post by vira28 »

Mostly an observation.

Many thought RDBMS is dead (at least 10 years ago), well here we are. Dynamic languages were all the craze and now pretty much all those languages added type safety (Typescript, recent Python versions)

Looks like what goes around comes around.

Folks like Martin Casado noticing the trend [1] and explained what was the challenge [2]

[1] https://twitter.com/martin_casado/status/1705969880225513815

[2] https://twitter.com/martin_casado/status/1706045633571041731

Re: Omnigres: Postgres as a Platform

#33

Post by canadiantim »

yrashk wrote: post #24
axelthegerman wrote: post #20

Earlier quoted context omitted.

I didn't read anything about edge computing in the project readme. Deploying a single instance would be the opposite of that. Unless you mean edge as opposed to mainstream?

It's not currently spelled out in the readme, but our approach does lend for straightforward shipping of complete systems (data + code) to the edge because it's effectively just a replication of the database. We're working on further primitives that facilitate such an operational model. We believe that a practical edge [backend] requires the presence of data next to the code, which is precisely what Omnigres promotes…

Does this mean omnigres could be used offline on mobile devices? Similar to an sqlite instance?

Re: Omnigres: Postgres as a Platform

#34

Post by samus »

ako wrote: post #31
axelthegerman wrote: post #21

Earlier quoted context omitted.

I hear you about the need for simplistic hosting. However I doubt shoving everything into the DB will get us there - besides some hardcore PG enthusiasts like OP & co. Sqlite together with the application layer of your choice seems to make much more sense to me, but hey we don't have to all like the same stuff (better we don't). Also without reading too much in detail but I wonder how testing/monitoring etc would be…

Why do you think shoving everything into a DB will not get us there. What about a scalable database platform like snowflake?

The language probably won't be perceived as "sexy" enough compared to, i.e., full-stack JavaScript. Most people don't really like SQL and aren't that good at it. Hence the continued popularity of ORMs that support the often-seen pattern of bulk-loading everything into the application server for processing instead of using a simple UPDATE statement.

Re: Omnigres: Postgres as a Platform

#35

Post by yrashk »

samus wrote: post #34
ako wrote: post #31

Earlier quoted context omitted.

Why do you think shoving everything into a DB will not get us there. What about a scalable database platform like snowflake?

The language probably won't be perceived as "sexy" enough compared to, i.e., full-stack JavaScript. Most people don't really like SQL and aren't that good at it. Hence the continued popularity of ORMs that support the often-seen pattern of bulk-loading everything into the application server for processing instead of using a simple UPDATE statement.

We're actually first-classing a number of languages and ecosystem support precisely so that people can use their languages of choice and not just SQL or Pl/pgSQL.

Re: Omnigres: Postgres as a Platform

#36

Post by yrashk »

Inviz wrote: post #26
yrashk wrote: post #18

Earlier quoted context omitted.

We don't really use connections but a pool of workers to process requests. Having http server tightly coupled with the database server makes for a responsive combo. We are still blocking workers, but prototyping improvements that will alleviate this.

Oh it's Yuri Rashkovskii, one name I actually remember from the olden times. I think you have a good project on hands, happy to see you could establish it as a tech startup. Over the years my mind keeps wandering into this place where an apps are much tigther integrated with the database. Where a full class of engineering tasks (and bugs caused by them) is eliminated completely. I'll be checking your progress.

Thanks! I am pleasantly surprised my name rings the bell for some :)

Re: Omnigres: Postgres as a Platform

#37

Post by bzzzt »

civilized wrote: post #11
lovasoa wrote: post #6

Nice to see Omnigres trending on hn; congratulations Yurii! The project is interesting, and thought provoking, because it goes against the often recommended "good practice" of separating storage and compute. Doing the exact opposite has a lot to offer in terms of performance, simplicity, and speed of development. I am currently also working on a database-first web application framework [1], with different goals and u…

> the often recommended "good practice" of separating storage and compute. This gets me thinking... has developer conventional wisdom ever recommended binding things together? Or does it only ever recommend more separation, more abstraction?

Object oriented programming prescribes binding code and data together in classes.

Re: Omnigres: Postgres as a Platform

#38

Post by jordanthoms »

This is an interesting project, but I'd be unlikely to use it, for a couple of reasons:

- In my experience the performance of the stateful DB server has been the biggest bottleneck when scaling - it's much easier to scale the stateless application servers which sit between end user requests and your DB in a traditional architecture. So usually I'm wanting to move as much work as possible away from the DB in order to squeeze the most out of it before needing to shard the DB or move to a different solution, rather than moving more responsibilities into the DB.

- It's frankly pretty scary to load a C extension into postgres which is opening ports and parsing requests etc - bugs in it could crash the server or open security holes, and if you were able to exploit a vulnerability you'd be able to grab any of the data in the DB and easily exfiltrate it. This would be less of an issue if using this for an internal service which isn't directly exposed to the internet, but it still could make it easier for an attacker to escalate their access. (This isn't a 'it should be rust' comment really, even if this was in rust it would still be pretty worrying).

- Even if think you only need simple CRUD actions, over time you tend to need more and more logic around those actions. Authentication, verification, triggering processes in other systems, maybe you make schema changes and need to adapt requests from old clients, etc. It's really nice to have a more heavyweight application server where you can implement that logic - I'm pretty skeptical that row level permissions, triggers etc will be able to cleanly handle all those as you add new requirements over time. This applies also to other tools for more directly exposing your DB ( e.g. PostgREST ). IMO starting off using a tool like this is really just setting you up to have to do a pretty painful rebuild later on.

Am I missing something here, maybe I have misunderstood the intended use case?

Re: Omnigres: Postgres as a Platform

#39

Post by tacone »

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.

Re: Omnigres: Postgres as a Platform

#40

Post by Twisell »

tacone wrote: 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/

Post reply on HN