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

271–280 of 286 posts

Re: PostgreSQL for Everything

#271

Post by oblio »

rjrjrjrj wrote: post #163
Ozzie_osman wrote: post #9

I love postgres and use it heavily, but I still don't fully understand how it overlook MySQL. Maybe because of Heroku adopting it. MySQL was generally faster, and while MyISAM was a bit limited Innodb was pretty powerful, and you had the choice. It was also simpler (imo) and avoided a lot of the xid/vacuum issues. That said, still love Postgres. But at the time it started eclipsing MySQL, MySQL felt better positioned…

Maybe things have changed, but my memory of MySQL ~15 years ago was that it was so... hacky. Basically, the (non-strict) JavaScript of the RDBMS world.

The PHP of the RDBMS world.

Re: PostgreSQL for Everything

#272

Post by oblio »

roryirvine wrote: post #50
jeremyjh wrote: post #22

Earlier quoted context omitted.

MySQL was always behind in terms of features. In early 2000s it had very limited constraints. Most people were running in ISAM backend and did not even have transaction support. It was being used by people who did not understand how advanced relational DBs were being used. What changed is Postgres overtook its actual competition, which were Oracle, SQL Server and Sybase. MySQL caught up as well as far as I know, but…

In the early days, PostgreSQL was so much more awkward to deal with. Crash-prone at first, and then there was the whole business around having to drop the db during upgrades. It didn't really match MySQL operationally until around 2002. During the dot com era it was common to develop and launch on MySQL with the intention of migrating to something else if they became successful (though your typical LAMP stack develop…

PostgreSQL didn't have real Windows support until... 2010? And even for LAMP, a lot of devs at the time were on Windows, they just deployed to prod on Linux.

Re: PostgreSQL for Everything

#274

Post by AdieuToLogic »

jghn wrote: post #245
AdieuToLogic wrote: post #209

Earlier quoted context omitted.

Sometimes to scale is "continue to satisfy SLAs as service usage increases" and other times to scale is "successfully evolve functional capabilities over time." While the GP may have been referencing the former, embracing "PostgreSQL for Everything" often prohibits the latter.

It *can* do that. I wouldn't say it's necessarily "often". Again, it's hard to predict the future. I think that the "use Postgres for everything" messaging was a necessity, even if it is overstated. Use it until you can demonstrate it doesn't meet your near term needs. When that happens, shift. It wasn't that many years ago when I'd enter situations where people were knee deep in FAANG level infrastructure when postg…

> It can do that.

As the old saying goes; just because you can do something doesn't mean you should do it.

> I think that the "use Postgres for everything" messaging was a necessity, even if it is overstated. Use it until you can demonstrate it doesn't meet your near term needs. When that happens, shift.

The problem with this approach is, once "use PostgreSQL for everything" is identified as being no longer be feasible, it has already become an inextricable component underpinning system functionality. Thus making "[w]hen that happens, shift" extremely difficult.

Contrast the above with only using PostgreSQL (or any other RDBMS) to manage data and their relationships, eschewing stored procedures as well, and the "when happens, shift" decision becomes much more feasible to entertain.

Re: PostgreSQL for Everything

#275

Post by devin »

joshuamoyers wrote: post #116
0cf8612b2e1e wrote: post #108

Earlier quoted context omitted.

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, Elas…

i think 1 billion DAU is the exception here, so I would not expect everyone to constantly caveat personally.

This is a ridiculous cutoff. Are you kidding?

Re: PostgreSQL for Everything

#276

Post by devin »

vb-8448 wrote: post #126
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.

> Postgres does not even come close to a full replacement for Elastic Size matters! For most of the application out there elastic (or kafka or any other specialized tool) is just too much(and too costly). They can do fine with postgres or mysql. Actually, I'd argue that in a lot of cases even postgres is too much, probably sqlite is enough.

What do you know about full text search? Faceted search? Custom tokenization? It is wild to see people talk about Postgres fulltext like it’s all you could need, even for small apps.

Re: PostgreSQL for Everything

#277

Post by devin »

pphysch wrote: post #103
devin wrote: post #68

Earlier quoted context omitted.

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.

Running a small ES with dual save alongside your relational store is trivial. Kafka I will grant you is a lot to operate, but I would not choose Kafka unless I have a Kafka-shaped problem, and if it looks like that I would never, ever choose Postgres. Equating Kafka with “I need a queue” is a laughable comparison.

Re: PostgreSQL for Everything

#278

Post by inigyou »

egwor wrote: post #240
vjvjvjvjghv wrote: post #228

Earlier quoted context omitted.

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.

Postgres is the right tool for most practical data storage jobs.

Re: PostgreSQL for Everything

#279

Post by jghn »

AdieuToLogic wrote: post #274
jghn wrote: post #245

Earlier quoted context omitted.

It *can* do that. I wouldn't say it's necessarily "often". Again, it's hard to predict the future. I think that the "use Postgres for everything" messaging was a necessity, even if it is overstated. Use it until you can demonstrate it doesn't meet your near term needs. When that happens, shift. It wasn't that many years ago when I'd enter situations where people were knee deep in FAANG level infrastructure when postg…

> It can do that. As the old saying goes; just because you can do something doesn't mean you should do it. > I think that the "use Postgres for everything" messaging was a necessity, even if it is overstated. Use it until you can demonstrate it doesn't meet your near term needs. When that happens, shift. The problem with this approach is, once "use PostgreSQL for everything" is identified as being no longer be feasib…

Eh, the "it's impossible to change later!" line is the classic one for any of these types of conversations. My experience over the decades has been that while yes, this can happen, it's grossly outweighed by YAGNI-in-retrospect and the eventual shift turning out to not be nearly as painful as people think once all of the people & bureaucratic problems are out of the way.

Re: PostgreSQL for Everything

#280

Post by groundzeros2015 »

bbkane wrote: post #252
groundzeros2015 wrote: post #219

Earlier quoted context omitted.

For example you can’t insert or update a SQLite view. I don’t even think SQLite lets you fully update a table schema. If you start trying to use it for sql and not just storing rows you run into these everywhere. SQLite is not serving the same needs as Postgres.

You can use a trigger with INSTEAD OF to update a view: CREATE TRIGGER update_customer_emails_trigger INSTEAD OF UPDATE ON customer_emails BEGIN UPDATE customers SET email = new.email, name = new.name WHERE id = old.id; END; Maybe that's not as flexible as you need. SQLites process for table updates can be pretty onerous if their ALTER TABLE lacks support. Its a 12 step process the docs have the temerity to call "sim…

Yes, friction like this. It’s just not a fully featured SQL implementation.

As their saying goes, it competes with fopen not oracle.

Post reply on HN