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

PostgreSQL is enough

gist.github.com

Post reply on HN
Print view View original

141–150 of 323 posts

Re: PostgreSQL is enough

#141

Post by api »

sgarland wrote: post #136
api wrote: post #61

No it's not, because it's very hard to set up in clustered HA environments. This is 2024. It should be possible to just add database nodes.

It is possible, if you pay for it. You can do Multi-AZ Clustered Instances in RDS, where you get the benefits of Multi-AZ failover with traffic sharing. If you can run your own infra – at least on an EC2 level – you can do things like Citus [0] for Postgres, which is about as close to "just add database nodes" as you'll get. [0]: https://www.citusdata.com/

Very clunky compared with things like CockroachDB.

Ultimately using something like Postgres in 2024 is just an on-ramp for expensive managed cloud database services, which is probably why it's promoted so much.

Re: PostgreSQL is enough

#142

Post by cnity »

deathanatos wrote: post #79
superb-owl wrote: post #2

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…

I have certain experience with some technologies, e.g., SQS and Postgres. Say I'm on your team, and you're an application developer, and you need a queue. If you're taking the "we're small, this queue is small, just do it in PG for now and see if we ever grow out of that" — that's fine. "Let's use SQS, it's a well-established thing for this and we're already in AWS" — that's fine, I know SQS too. I've seen both of th…

This desire can sometimes be so strong that people insist on truly wacky decisions. I have before demonstrated that Postgres performs perfectly well (and in fact exceeds) compared with a niche graph database, and heard some very strange reasons for why this approach should be avoided. A lot of the time you hear that it's engineers who chase shiny technology, but I've seen first hand what can happen when it's leadership.

Re: PostgreSQL is enough

#143

Post by cpursley »

dfee wrote: post #74
brightball wrote: post #58

Earlier quoted context omitted.

PG works really well as a message queue and there's several excellent implementations on top of it. Most systems are still going to need Redis involved just as a coordinator for other pub/sub related work unless you're using a stack that can handle it some other way (looking at BEAM here). But there are always going to be scenarios as an application grows where you'll find a need to scale specific pieces. Otherwise t…

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.

Re: PostgreSQL is enough

#144

Post by SparkyMcUnicorn »

redskyluan wrote: post #127

Regarding scale, PostgreSQL may not cover all bases. Though I'm a PostgreSQL fan, I prefer specialized services for specific tasks. Using PG-based plugins could help, but a dedicated SQL-compatible database is often a better fit. For vector retrieval, going with a database like Milvus, designed for vectors, is usually more efficient and cost-effective. Similar principles apply across domains. Is there any vectordb un…

pgvector[0] is supported by AWS RDS, Azure, etc.

I haven't gotten a chance to try out Latern[1] yet, but have heard some good things[2].

[0] https://github.com/pgvector/pgvector

[1] https://github.com/lanterndata/lantern

[2] https://tembo.io/blog/postgres-vector-search-pgvector-and-la...

Re: PostgreSQL is enough

#145

Post by cpursley »

legohead wrote: post #78
superb-owl wrote: post #2

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…

My saying has always been: be nice to the DB Don't use it anymore than you have to for your application. Other than network IO it's the slowest part of your stack.

Handling business logic in the database is often going to be an order of magnitude faster than the application layer of some of the popular language stacks (looking at you, Rails, Node, etc). It also will outlive whatever webstack of the day (and acquisition which of en requires a re-write of the application layer but keeps general database structure - been there done that).

Re: PostgreSQL is enough

#146

Post by cpursley »

philippemnoel wrote: post #84

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…

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.

Re: PostgreSQL is enough

#147

Post by cpursley »

runningamok wrote: post #119
Ensorceled wrote: post #39

Earlier quoted context omitted.

> [...] sqlite is the 80% case and is also dead simple to get going and genuinely performant. I don't understand this. PostgreSQL is ALSO dead simple to get going, either locally or in production. Why not just start off at 90%? I mean, I get there are a lot of use cases where sqlite is the better choice (and I've used sqlite multiple times over the years, including in my most recent gig), but why in general?

One use case where SQLite is a good option is for embedding as a local database in an app. Starting local-only with SQLite allows you to defer a lot of the backend effort while testing an MVP.

You might find https://github.com/electric-sql/electric pretty cool.

Re: PostgreSQL is enough

#148

Post by cpursley »

adlpz wrote: post #5

Love postgres and use it extensively. However, there's always an issue when I start doing the more advanced stuff: how do I combine that with all my years of experience with version control, code reviews, types, tests, static analysis and all the niceties of coding in general? Migrations?

Migrations. All my database logic lives in version control.

Popular tooling like Phoenix, Hasura, etc have good built in migration stories.

https://www.bytebase.com looks really promising.

Hover, I do struggle with one big issue: changing database logic (views, functions, etc) that has other logic dependent on it. This seems like a solvable problem.

Re: PostgreSQL is enough

#149

Post by cpursley »

vmfunction wrote: post #28
adlpz wrote: post #5

Love postgres and use it extensively. However, there's always an issue when I start doing the more advanced stuff: how do I combine that with all my years of experience with version control, code reviews, types, tests, static analysis and all the niceties of coding in general? Migrations?

If you want to serious develop postgres as how you develop code, then you should also use a LSP. https://github.com/supabase/postgres_lsp

Thanks, I need to add this to my list as well.

Re: PostgreSQL is enough

#150

Post by Too »

niels_bom wrote: post #111
legohead wrote: post #78

Earlier quoted context omitted.

My saying has always been: be nice to the DB Don't use it anymore than you have to for your application. Other than network IO it's the slowest part of your stack.

Would you say it's slower than file IO too?

It’s not slow by itself. It’s a single point of bottleneck that will inevitably become slow as you cram everything into it.
Post reply on HN