Could you write an OS based on PostgreSQL?:)
Not quite an OS, but they are doing some neat things: https://omnigres.com/
PostgreSQL is enough
181–190 of 323 posts
Re: PostgreSQL is enough
#182This is really ridiculous
Specifically how so?
Re: PostgreSQL is enough
#183It's enough until you start working with json and how painful it is to manipulate data.
Postgres is great at json, I use it a bunch.
Re: PostgreSQL is enough
#184I'm one of the makers of ParadeDB, a modern alternative to Elasticsearch. We build Postgres extensions to do fast search (pg_bm25) and analytics (pg_analytics). I love Postgres. If you have a small workload, like a startup, it certainly makes sense to stay within Postgres as long as you can. The problem is, at scale, Postgres isn't the answer to everything. Each of the workloads one can put in Postgres start to grow…
For scaling, has anyone here used hash based partitioning to scale horizontally? In principle, seems like it should work to allow large scale distribution across many servers. But the actual management of replicas and deciding which servers to place partitions, redistributing when new servers are added, etc. could lead to a massive amount of operational overhead.
Citus is indeed an example for "distributed PostgreS". There are also serverless Postgres (Neon, Nile, AWS Aurora) which do this.
If you are interested in partitioning in an OLAP scenario, this will soon be coming to pg_analytics, and some other Postgres OLAP providers like Timescale offer it already
Re: PostgreSQL is enough
#185I use Postgres for a lot, but I can't imagine using it to make HTTP requests.
Re: PostgreSQL is enough
#186I'm one of the makers of ParadeDB, a modern alternative to Elasticsearch. We build Postgres extensions to do fast search (pg_bm25) and analytics (pg_analytics). I love Postgres. If you have a small workload, like a startup, it certainly makes sense to stay within Postgres as long as you can. The problem is, at scale, Postgres isn't the answer to everything. Each of the workloads one can put in Postgres start to grow…
This looks great, I'll add it to my list. I've gone far out of my way not to use Elasticsearch and push Postgres as far as as I can in my SaaS because I don't want the operational overhead.
This is exactly why we built ParadeDB :)
Re: PostgreSQL is enough
#187If you twist yourself into a pretzel enough you can make Bash do all these things. Doesn't make it a good idea. The biggest problem with depending on Postgres is it's a large complex monolith. Any problem you have only has two possible solutions: 1) spend a ton of time trying to twist yourself into a more pretzely shape to get it to do what you want, or 2) replace that thing you wanted with some external thing. Both…
> I don't want to learn new things
I've learned a bunch of new things (running all the things - not fun, putting biz logic in the application layer - slow).
Putting them in the database is simply simpler and more performant. And it requires less code and time to develop (and maintain).
Re: PostgreSQL is enough
#188Write me when you can change column order or type
You can change type.
But that's a good point regarding column order, sometimes I find myself wanting to do that.
Re: PostgreSQL is enough
#189What about offline sync
Re: PostgreSQL is enough
#190I'm one of the makers of ParadeDB, a modern alternative to Elasticsearch. We build Postgres extensions to do fast search (pg_bm25) and analytics (pg_analytics). I love Postgres. If you have a small workload, like a startup, it certainly makes sense to stay within Postgres as long as you can. The problem is, at scale, Postgres isn't the answer to everything. Each of the workloads one can put in Postgres start to grow…
For scaling, has anyone here used hash based partitioning to scale horizontally? In principle, seems like it should work to allow large scale distribution across many servers. But the actual management of replicas and deciding which servers to place partitions, redistributing when new servers are added, etc. could lead to a massive amount of operational overhead.
hash based partitioning makes repartitioning very expensive. most distributed DB now use key-range based partitioning. Iirc, Dynamo which introduced this concept has also made the switch