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

231–240 of 286 posts

Re: PostgreSQL for Everything

#231

Post by theultdev »

andai wrote: post #155
crazygringo wrote: post #153

Earlier quoted context omitted.

Not really. They are two different paradigms. Use the one that is right for you. SQLite is embedded for local applications with one writer mostly. Postgres is for a client-server architecture with many writers. When you start a project, you generally know which architecture you need.

So if it needs to work offline, but it syncs with a server, then you use both? (And the schema becomes some kind of lowest common denominator?)

yeah essentially, see electricsql

though they also have "pglite" running in wasm.

same concept though, sync slices to an embedded db.

Re: PostgreSQL for Everything

#232

Post by ezekiel68 »

Bona Fides: I learned c on with the K&R book on an Amiga (and transitioned to enterprise software engineering from there).

This seems like one more "When all you have is a hammer, everything looks like a nail" take. I agree with the other commenters who advocate for best-of-breed (e.g. Kafka, etc. for a message queue). PS I freakin love PostgreSQL as a relational (or even a time-series or OLAP) DB.

Re: PostgreSQL for Everything

#233

Post by micw »

Tetris on postgres? Not doom? So not a candidate for everything!

Just kidding. Of course there's doom for postgres: https://github.com/cedardb/DOOMQL (pure SQL) and https://github.com/DreamNik/pg_doom (extension).

Oh and there's https://github.com/snaplet/postgres-wasm that allows to run everything else in postgres ^^

Re: PostgreSQL for Everything

#234

Post by [deleted] »

actionfromafar wrote: post #56
radiospiel wrote: post #6

Earlier quoted context omitted.

Well, the poster explicitly talks about 2003 here: „ In 2003, MySQL was much more widely used than PostgreSQL. MySQL was also potentially faster as it did not implement all features of the SQL standard“

Didn't very early mysql play fast and loose with the concept of actually syncing to disk? That was also fast. Web scale fast. :)

[deleted]

Re: PostgreSQL for Everything

#235

Post by raverbashing »

throwitaway222 wrote: post #197
majormajor wrote: post #111

Earlier quoted context omitted.

If you start here, with the "Postgres will take you wherever you need to go" meme, without thinking extremely deeply about your schema and how you expect to evolve it in the future, you can easily paint yourself into a very difficult and expensive corner. It's easy to use Postgres poorly in ways that result in painful centralized bottlenecks. (Obviously this is largely true for anything , but I think that in 2026, wh…

A counter anecdata. We transitioned from a postgres job queue to Rabbit. We had never ending problems after that, many of them were misunderstandings, some where just wrong-fit. We migrated because we had some time on our hands and thought we would alleviate some high pressure jobs. Not only did it not solve the problem, but having written all the code that decides when to pull the next message and what to do with it…

Honestly Rabbit sucks more than it shines

Also it is very "unconventional". Everything has to be done in its weird and quirky way

Re: PostgreSQL for Everything

#236

Post by bpavuk »

ballon_monkey wrote: post #195
bpavuk wrote: post #77

Earlier quoted context omitted.

EF Core is so easy to turn into a disgrace for performance, developer experience, AND build times...

Yeah this really isn't so true anymore. I was a diehard Dapper fan for a long time, but the performance of EF Core is comparable to Dapper now. Dropping down to SQL in EF Core is super easy and parameterized. I just don't even bother with Dapper anymore. I have an app with ~200k users with the slowest query being ~6ms and of 1000s of queries only 3 are hand rolled complicated SQL written for perf executed via EF Core…

if you knew how to cook it, you could use make older EF Core (and original EF) go brrr. you sound like you do know. my problem is that it is hard to find out what exactly is the best without dropping down several abstraction layers, sometimes, as you noted, to raw SQL.

why not just construct SQL queries in a type-safe DSL, like, say, JetBrains Exposed does? you are writing what's basically SQL that your compiler understands and your existing tooling checks for free. (granted, C# may need an additional Roslyn analyzer, but it's still simpler than either guessing what transaction LINQ will make or writing SQL in strings.)

Re: PostgreSQL for Everything

#237

Post by cheikhcheikh »

vjvjvjvjghv wrote: post #228
dorfsmay wrote: post #203

Earlier quoted context omitted.

I tried very hard to use postgres as a queue, it was robust but slow once I started to push from more than a few processes/servers. Moving to zeromq initially and sqs after solved all my perf issues, and was still solid.

I think that’s the way to go. Start with Postgres and only if there are problems, then think about something more specialized. Same for microservices. Start simple and introduce a service when really needed. I hate it when people already start out with 10 or more different systems/services for a few messages per second.

it's not the way to go if you hit the limits very quickly and have to waste immense time migrating.

Re: PostgreSQL for Everything

#238

Post by raverbashing »

cyh555 wrote: post #105
stackskipton wrote: post #94

Earlier quoted context omitted.

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?

I love the naming Kafka. Either they knew what it stands for or they didn't. And the latter is the worse option.

Re: PostgreSQL for Everything

#239

Post by raverbashing »

dwedge wrote: post #154
cyh555 wrote: post #105

Earlier quoted context omitted.

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

This problem doesn't go away with postgres. It's totally anecdotal but this is one thing that I've noticed different in mysql shops and postgres shops - with mysql there is usually at least one person on staff who knows MySQL DBA and scaling pretty well, with postgres it's rarely the case to have someone who knows the internals well - like you said, the person capable of maintaining it when it goes wrong. You could a…

> You could argue it's because postgres requires less poking though

This is the myth people who parrot "just use Postgres" believe. It is false, obviously

Re: PostgreSQL for Everything

#240

Post by egwor »

vjvjvjvjghv wrote: post #228
dorfsmay wrote: post #203

Earlier quoted context omitted.

I tried very hard to use postgres as a queue, it was robust but slow once I started to push from more than a few processes/servers. Moving to zeromq initially and sqs after solved all my perf issues, and was still solid.

I think that’s the way to go. Start with Postgres and only if there are problems, then think about something more specialized. Same for microservices. Start simple and introduce a service when really needed. I hate it when people already start out with 10 or more different systems/services for a few messages per second.

I think that using the right tool for the job is important and saves a lot of time in the long run. There are expensive headaches that we have to resolve.
Post reply on HN