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

PostgreSQL is enough (2024)

gist.github.com

Post reply on HN
Print view View original

91–97 of 97 posts

Re: PostgreSQL is enough (2024)

#91

Post by groundzeros2015 »

clncy wrote: post #83
groundzeros2015 wrote: post #36

Earlier quoted context omitted.

Why is it easier? You don’t need to operate on the entire database. You can backup or roll back individual tables and schemas.

You can do it, but if you stuff that process up (e.g. touch the wrong tables/schemas) you’re now dealing with a more complex recovery. Also are you applying migrations with CREATE OR REPLACE etc? I find that much harder to collaborate on than just standard code.

You only need to migrate if you care about the data and once again that can be different for each schema. And the inverse is true, if you don’t migrate it’s because you’re not preserving data.

Re: PostgreSQL is enough (2024)

#93

Post by frollogaston »

efficax wrote: post #92
frollogaston wrote: post #54

Earlier quoted context omitted.

Maybe with TimescaleDB?

i mean sure, but that's a whole other storage engine that uses postgres as the frontend. it's basically another database entirely

Not really, it uses regular Postgres tables and indexes under the hood

Re: PostgreSQL is enough (2024)

#95

Post by fastball »

mindwok wrote: post #68
fastball wrote: post #5

> But the bar should be high: only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative Why do I need to push Postgres to its limits before using a different solution? Throwing a hosted Redis in front of some hot-path API calls is very straightforward and easier to reason about than materialized views or UNLOGGED tables.

I haven't really used redis much so curious to hear your perspective - this seems the opposite to me? A materialised view is just taking the data I already have and rendering it in a different way to speed up my access patterns. It's easy for me to understand where its all coming from, and it's all directly mapped back to the source data so if things change I can easily understand why it might break etc. For redis, i…

Hot paths are basically never entirely comprised of your db query directly – they are part of some business logic contained in a backend service. So: you identify that "this API route is called a lot, but doesn't always need the exact data at time of call", and then you do this:

cached_val = redis.get(MY_CACHED_KEY);

if (cached_val) return cached_val;

db_val = pg.select(...);

redis.set(MY_CACHED_KEY, db_val, ttl=60s);

return db_val;

Imo this is much easier to grok/reason about than materialized views, and has the added benefits of: it is much faster than your db query if cache is set, there is some amount of robustness if your db is temporarily unavailable, you don't need to worry about "is my cache being backed up and costing me money because its part of my persistent db", etc

Basically, the point is: if you are using some hyperscaler to host your stuff (most people), then you already have trivial access to other services beyond postgres, and shoving everything into postgres might not actually be easier than using things that were purpose-built for your problems-that-are-not-actually-the-shape-of-a-persistent-relational-db.

Fwiw I love Postgres.

Re: PostgreSQL is enough (2024)

#96

Post by marvinstrauch »

efficax wrote: post #34

is it though? not for time series workloads with billions of rows it isn’t

100% agreed. Had recently a few million rows of stats in a relational DB (not exactly Postgres but it'd be the same) and the table was already way bigger than the same data in a TSDB. And that's just the storage side, before query performance even comes into it.

Re: PostgreSQL is enough (2024)

#97

Post by mindwok »

fastball wrote: post #95
mindwok wrote: post #68

Earlier quoted context omitted.

I haven't really used redis much so curious to hear your perspective - this seems the opposite to me? A materialised view is just taking the data I already have and rendering it in a different way to speed up my access patterns. It's easy for me to understand where its all coming from, and it's all directly mapped back to the source data so if things change I can easily understand why it might break etc. For redis, i…

Hot paths are basically never entirely comprised of your db query directly – they are part of some business logic contained in a backend service. So: you identify that "this API route is called a lot, but doesn't always need the exact data at time of call ", and then you do this: cached_val = redis.get(MY_CACHED_KEY); if (cached_val) return cached_val; db_val = pg.select(...); redis.set(MY_CACHED_KEY, db_val, ttl=60s…

Ah I hadn't considered the case of querying an API call rather than DB one. That makes perfect sense. Thanks!
Post reply on HN