Live data from Hacker News

PostgreSQL is enough

gist.github.com

171–180 of 323 posts

Re: PostgreSQL is enough

#171
post #73
post #19

Earlier quoted context omitted.

I think a lot of the industry struggles with the idea that maybe there is no "one size fits all", and what makes sense when you're a one person company with 100 customer probably doesn't make sense when you're a 1000 people company with millions of customers. If you use a stack meant for a huge userbase (with all the tradeoffs that comes with it) but you're still trying to find market fit, you're in for a disappointm…

> It's OK to make a choice in the beginning based on the current context and environment, and then change when it no longer makes sense. Yep. And Postgres is a really good choice to start with. Plenty of people won't outgrow it. Those who do find it's not meeting some need will, by the time they need to replace it, have a really good understanding of what that replacement looks like in detail, rather than just some h…

True enough and with modern hardware that barrier is relatively high. IIRC Stack overflow was handling several million users in a single database server over a decade ago... We've got over 8x the compute power and memory now.

Still need to understand the data model and effects on queues though.

Re: PostgreSQL is enough

#172

I often go down rabbit holes like this, trying to collapse and simplify the application stack. But inevitably, as an application grows in complexity, you start to realize _why_ there's a stack, rather than just a single technology to rule them all. Trying to cram everything into Postgres (or lambdas, or S3, or firebase, or whatever other tech you're trying to consolidate on) starts to get really uncomfortable. That s…

The more I do fullstack work the more I see an obesity crisis. I under the need to modularize (I dearly think I do) but god you have relational model, reimplemented in your framework, reencoded as a middleware to handle url parsing, the one more layer to help integrate things client side. I find that insane. And Postgrest was a refreshing idea.

Re: PostgreSQL is enough

#173
post #74

Earlier quoted context omitted.

Worth noting that Postgres has a pubsub implementation built in: listen/notify. https://www.postgresql.org/docs/current/sql-notify.html

Yep, I should add that. One of the libraries in my list (that I maintain) is WalEx: https://github.com/cpursley/walex/issues It subscribes to the Postgres WAL and let you do the same sort of thing you can do with listen/notify, but without the drawbacks like need for triggers or character limits.

Going to add this to my research list.

Re: PostgreSQL is enough

#174
I'm gonna go ahead and make a half-serious half-joking hot take:

Actually you should be using an embedded database.

Half-joking because there's like, tons of infrastructure, both literal and theoretical, that you're gonna miss out, and because I'm not sure we have on-disk standards (so less "good software" than "popular software") other than sqlite and libdb, both of which have some issues that make me hesitate before saying "use this."

But often the reason you're ignoring 90% of your RDBMS is because you for some (good or bad) reason want it elsewhere, and the built-in stuff can even get in the way a bit. And this approach means you no longer have to worry about how to version the stored procedures or whatever.

In a way, this is the same take as that gist, but inside out - instead of putting all your code inside Postgres, put Postgres inside your code.

Re: PostgreSQL is enough

#175

On the [Simplify: move code into databases]( https://sive.rs/pg ), has anyone actually tried this? My instinct is that the output won't be simpler at all, but a big twisty web of varying parts and competing use cases, all extremely hard to discover. To me, having two things that do something distinct is simpler, and ironically, Rich Hickey says this exact thing in Simplicity Matters, which is quoted in the article.

Having two distinct things doesn't mean placing them in separate processes. Or we'd all be writing Erlang by now

We kinda all are writing Erlang now, just inferior and overly complex abstractions ("serverless", K8s, etc).

Re: PostgreSQL is enough

#176
post #10

Obligatory "depends". I'm aware of more than one company that uses postgres for huge datasets serving workflows with high throughput and importance. It's truly a workhorse, it's comparatively a pleasure to work with, and its extensibility makes it useful in places some other DBs aren't suitable for. But a relational DB isn't right for every workload.

> But a relational DB isn't right for every workload. While sometimes true, I'll counter that it's more common that the application was not truly designed for a relational DB, and instead was designed for reading and storing JSON.

What's more common is domain dependent.

Re: PostgreSQL is enough

#177

I'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.

I think that's what Citus does.

Re: PostgreSQL is enough

#179
post #17

Could you write an OS based on PostgreSQL?:)

I've thought about writing a general-purpose programming language that uses Postgres as its runtime, with the twist that it can save checkpoints to survive system reboots and also interop closely with SQL. Postgres already has a lot of nice built-in types and functions.

Re: PostgreSQL is enough

#180

btw recently cleaned up my wal cache busting code quite a bit if you're interested. https://github.com/Logflare/logflare/blob/main/lib/logflare/... Need to make a lib out of this!!

Thanks from one Elixir-using Chase to another ;)
Post reply on HN