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

PostgreSQL for Everything

raphaelbauer.com

Post reply on HN
Print view View original

101–110 of 286 posts

Re: PostgreSQL for Everything

#101

Post by aaaronic »

orev wrote: post #90
erlich wrote: post #26

It's more "what one tool can do everything", not that its ideal. Like why people use Microsoft Teams even though its terrible. The relational model and sql force us to simplify our data models too much by eliminating relationships or just not dealing with them. Think about a nested json blob from some web service api and storing it in SQL in normalized tables. No one is going to do that. Everything just becomes a den…

I think you’re responding to the general idea of a relational database, not Postgres, and definitely not what’s in the article (DR;CA). Postgres has built in data types and functions that allows it to work with unstructured json documents, like you would use in MongoDB.

That feature is definitely part of why it's still so relevant. The hstore approach wasn't nearly enough when it was all PG offered.

Re: PostgreSQL for Everything

#102

Post by OutOfHere »

lenkite wrote: post #99
OutOfHere wrote: post #87

Earlier quoted context omitted.

Are you saying that STRICT was insufficient for you? What more did you want beyond one of: INT, INTEGER, REAL, TEXT, BLOB, ANY? https://sqlite.org/stricttables.html

Want SQL-92 standard DATE/TIME/TIMESTAMP.

Can't those be stored as integers with a desired resolution?

Re: PostgreSQL for Everything

#103

Post by pphysch »

devin wrote: post #68
dewey wrote: post #61

Earlier quoted context omitted.

The point is in general for people to just consider it, often people start out on their side projects or internal company projects and commission Elastic, Redis, Postgres, Kafka before even getting started. In reality they could fit it all into Postgres for a very long time. Nobody is saying that a huge ecommerce store with complicated filtered search logic should throw away their Elasticsearch cluster and switch to…

If you actually start looking into these things, you often start looking at custom pg extensions, which means you just made the decision to "simplify" your stack by maintaining your own postgres cluster with custom extensions. This is just papering over the fact that you're increasing the complexity and saying "well it's still just postgres!" as you do it.

Installing & maintaining a Postgres extension is vastly, vastly simpler than running Elasticsearch and Kafka. Like, how could you even compare these things if you know what you are talking about?

Or maybe you are looking at it from "just swipe your credit card at AWS" perspective, in which case "just use Postgres" articles are for a different audience.

Re: PostgreSQL for Everything

#105

Post by cyh555 »

stackskipton wrote: post #94
HighlandSpring wrote: post #41

This isn't just theory either, for example: Revolut is a bank that does all its event persistence and streaming on top of postgres. No traditional message queues/brokers in their stack. https://medium.com/revolut/recording-more-events-but-where-w...

As SRE dealing with this at current company, a benefit of using well known software like Kafka is a lot of problems you will run into have solutions/guidance already available vs you having to explore solutions which a lot of time end with “Kafka could easily do this. “

100% except when Kafka goes wrong, who maintains it?

Re: PostgreSQL for Everything

#106

Post by cauchyk »

as someone who loves postgres, this take is getting pretty old. yes we can do quite a bit with extensions but extensions often need to interface with external systems and even then managed providers don't consistently support all extensions. some gaps: bm25 indexes, olap support, also extensions also run into licensing restrictions.

Re: PostgreSQL for Everything

#107

Post by zelphirkalt »

thatwasunusual wrote: post #73
zulux wrote: post #67

Earlier quoted context omitted.

Perfectly reasonable: I'm a huge PG fan, so I start everything with it, but SQLite is sane, and it generally has a happy upgrade path to PG If you need it.

It's the other way around for me: as 99% of the stuff I develop is .NET (and I use EF Core for database stuff), I can get away with SQLite for local development, prototyping (and even staging), and then just "flip a switch" for it to run on production PostgreSQL. Both are amazing technologies.

I can't recommend this "switch". If you are not testing locally with the same relational database as in production, you can miss mistakes and bugs. This is not just theoretical. One example where I thought I will be fine using SQLite was with a small Django project. But time and time again I ran into limitations of either SQLite or Django's database adapter for SQLite, when it came to dealing with many to many relationships in the model and through tables, requiring me to work around the limitations. There is no guarantee, that these workarounds in turn will work the same in PostgreSQL in production.

Anyway, it is a basic practice of keeping test and dev environment as close as feasible to production, to avoid missing issues and wrong assumptions.

Re: PostgreSQL for Everything

#108

Post by 0cf8612b2e1e »

devin wrote: post #30

This kind of post (Postgres! It's all you need!) is getting pretty tiresome. Postgres does not even come close to a full replacement for Elastic, and that's just the first bullet. Looking down the list it is pretty easy to go: Yes, postgres can be used instead of that for extremely basic use cases, but it all goes out the window you actually need any of the power of these other tools.

I think it would be helpful if some of these posts included scale. There are almost always two groups talking past each other

  - I run my B2B application, Postgres only, and it is perfect for my 50k MAU. No complaints, sleeping soundly with the low complexity and a two man team. 
  - I work at FAANG, where we have 1 billion DAU, and this is a joke. Would fall over immediately. The dedicated ops teams for Kubernetes, Elastic, and Redis have never complained about scaling issues.

Re: PostgreSQL for Everything

#109

Post by pelzatessa »

Hey Raphael Bauer, if you're reading this, I suggest you change the color of hrefs on your website, all of them are purple and underlined, which usually is indicator for "Already visited URL". For me that's not that much of a problem, but it was something i kept noticing when reading the article. I wonder if anyone else also had this thought or am I alone as I didn't see anyone else mention this in the comments. But I wanted to signal that nevertheless :)

Re: PostgreSQL for Everything

#110

Post by andriy_koval »

HighlandSpring wrote: post #41

This isn't just theory either, for example: Revolut is a bank that does all its event persistence and streaming on top of postgres. No traditional message queues/brokers in their stack. https://medium.com/revolut/recording-more-events-but-where-w...

they likely have something on top of PG to distribute data across shards, which is still untrivial task I think and require ops overhead.
Post reply on HN