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

191–200 of 286 posts

Re: PostgreSQL for Everything

#191

Post by sgarland »

idoubtit wrote: post #18

Why write a fanboy text with unfair comparisons that hide the Postgres limitations? For instance, for many simple needs MySQL is simpler than Postgres, with similar performance and consistency. * No need for a connection pool, while many use cases with Postgres require PgBouncer and Co. * Easy sort (and basic search) of multilingual text, because MySQL has case insensitive UTF8 collations. * No need to VACUUM, which…

> case-insensitive

Tbf you can also achieve this in Postgres, it's just not present by default. From the docs [0]: CREATE COLLATION ignore_accent_case (provider = icu, deterministic = false, locale = 'und-u-ks-level1');

0: https://www.postgresql.org/docs/current/collation.html

Re: PostgreSQL for Everything

#192

Post by jeremyjh »

est31 wrote: post #88
ericpauley wrote: post #27

Postgres is great, but I certainly don't think it's great for everything. For instance, while you can in theory implement OLAP aggregation you're going to be hand-rolling a bunch of stuff that something like Clickhouse gives you for free declaratively.

With Lakebase Postgres you can do this very easily: https://docs.databricks.com/aws/en/oltp/projects/quickstart-... It is already a quite smooth experience, but there is work to make it even easier than that. I work on Lakebase, opinions my own.

As a big fan of Postgres, Databricks and Lakebase: Lakebase is not Postgres, and this is just CDC.

Re: PostgreSQL for Everything

#193

Post by boznz »

psadauskas wrote: post #139

My general rule of thumb is "Use Postgres until you've discovered why you can't use Postgres." Anything you introduce is another moving part you have to operate and maintain, and in the beginning, Postgres can probably handle it. Wait for load, see where its failing, and then you'll have a better idea if adding another tool is worth the cost.

Another rule of thumb. Use what you are comfortable with until it stops doing what you want.

Re: PostgreSQL for Everything

#194

Post by jeremyjh »

tpetry wrote: post #184
ericpauley wrote: post #57

Earlier quoted context omitted.

The article says verbatim “PostgreSQL Replaces Clickhouse”. Coming from storing billions of rows in Clickhouse and performing dozens of materialized operations I shudder to think about what that would look like in a DB that doesn’t even support declarative IVM.

The article suggested using TimescaleDB which has its own concept of IVM: continuos aggregates. And compared to the approach by ClickHouse it can also update the materialized views when you update/delete old raw data https://sqlfordevs.com/books+courses/timescale/05-continuous...

Yes but that is just one use case. Columnar OLAP engines operating on object storage can do all kinds of stuff so much better than Postgres that it may as well be a completely different capability. That said - the point is that you can get a lot further with just Postgres than many people think, and now we also have options like pg_lake. But I wish I'd changed analytics platforms A LOT sooner than I did.

Re: PostgreSQL for Everything

#195

Post by ballon_monkey »

bpavuk wrote: post #77
thatwasunusual wrote: post #73

Earlier quoted context omitted.

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.

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.

Re: PostgreSQL for Everything

#196

Post by ballon_monkey »

ChicagoDave wrote: post #137

This is exactly how tightly coupled, unmaintainable software is constructed. By picking the tools before understanding the model and building bespoke architecture. You pick the tools that the business model requires. It might be a relational data store. It might not be. You might want an event store. You might want to reduce costs with lambdas and DynamoDB. You may need a pub/sub event broker. The OP clearly loves Po…

> This is exactly how tightly coupled, unmaintainable software is constructed.

No. If you're struggling to build software against a DB and then abstract parts to use Redis or ES or whatever in the future, that's kinda a skill issue you or your team have with building poor software to begin with. Nothing to do with using a DB for multiple things like a Queue/Search etc.

Re: PostgreSQL for Everything

#197

Post by throwitaway222 »

majormajor wrote: post #111
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...

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, and how to dead-letter it - just worked great for us on Postgres. It was so easy to understand and doing things like reprocessing just using a standard postgres DB interface was much easier.

Ultimate the entire processing got removed from our team and no longer needs to do these deployments (acquisition transitions)...

Re: PostgreSQL for Everything

#198

Post by rtpg »

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.

Even just B2B vs B2C is a huge split. Plenty of specialized ERPs in the world that have relatively few "butts in seats" users but have a lot of data to work through.

Size of the data, read/write ratio, number of "requests"... lots of axes that change how much pain or not you're in by just pointing to pg

Re: PostgreSQL for Everything

#199

Post by Geof25 »

boznz wrote: post #193
psadauskas wrote: post #139

My general rule of thumb is "Use Postgres until you've discovered why you can't use Postgres." Anything you introduce is another moving part you have to operate and maintain, and in the beginning, Postgres can probably handle it. Wait for load, see where its failing, and then you'll have a better idea if adding another tool is worth the cost.

Another rule of thumb. Use what you are comfortable with until it stops doing what you want.

Well the problem is that sometimes there is just too much choice to make

Re: PostgreSQL for Everything

#200

Post by LAC-Tech »

crazygringo wrote: post #153
andai wrote: post #140

Earlier quoted context omitted.

Doesn't the same argument apply even more to using SQLite instead?

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.

SQLite is embedded for local applications with one writer mostly.

In 2026 that advice feels antiquated. SQLite now is absolutely useful now for concurrent, mutli-writer applications.

https://www.sqlite.org/src/doc/wal2/doc/wal2.md

Post reply on HN