> Tell me you don't understand Redis point is data structures without telling me you don't understand Redis point is data structures.
regardless of the author, I think slop of that sort belongs on reddit, not HN.
They may be its point, but I frankly didn't see much use in the wild. You might argue that then those systems didn't need Redis in the first place and I'd agree, but then note that that is the point tigerdata makes.
edit: it's not about serious uses, it's about typical uses, which are sad (and same with Kafka, Elastic, etc, etc)
What I like about the "just use PostgreSQL" idea is that, unfortunately, most people don't use Redis well. They are just using it as a cache, which IMHO, isn't even equivalent to scratching the surface of all the amazing things Redis can do.
As we all know, it's all about tradeoffs. If you are only using Redis as a cache, then does the performance improvement you get by using it out weight the complexity of another system dependency? Maybe? Depends...
Side note: If you are using Redis for caching and queue management, those are two separate considerations. Your cache and queues should never live on the same Redis instance because the should have different max-memory policies! </Side note>
The newest versions of Rails have really got me thinking about the simplicity of a PostgreSQL only deployment, then migrating to other data stores as needed down the line. I'd put the need to migrate squarely into the "good problems" to have because it indicates that your service is growing and expanding past the first few stages of growth.
All that being said, man I think Redis is sooooo cool. It's the hammer I am always for a nail to use on.
That being said, while I think Postgres is “the right tool for the job” in many cases, sometimes you just want (relative) simplicity, both in terms of complexity and deployment, and should use something like SQLite. I think it’s unwise to understate simplicity, and I use it to run a few medium-traffic servers (at least, medium traffic for the hardware I run it on).
i personally like postgres myself for just about all use cases that must be shared with others (app with more than one client that might be providing CRUD updates or anything really that demands a central data store). ive used sqlite a couple times with WAL to try and make a small app shared between 2-3 people who all would contribute updates thru it but it wasnt ideal. for postgres so many features/extensions its concurrent writes are fast as hell and if you just want to one-shot a solution then you cant go wrong, but it's ofc not the same as sqlite setup.
i think a lot of the pain with postgres is just learning to effectively be a knowledgeable db admin of sorts. its somewhere between being a competent devops guy and a dbadmin expert all in one. if you're actually doing some kind of production deployment it is kinda scary hoping you've got everything set up right. even supabase which makes this whole process trivial to get going requires an understanding of not-always-understood security premises that just make things spooky.
lot of words to say i dont get much out of these discussions tbh. theres just too many use cases and variables in everyones working/hobby lives im not sure that there is a proverbial bottom to any of it. some will use sqlite and some will use postgres and some will use some weird thing no ones heard of because they're afraid to rawdog sql and just want immediate graphql capability to be the main mode of data retrieval. some will show up here and talk about why you need redis in the middle.
its too much noise so i just keep using postgres because its free and boring and fast. end of the day i just want to make stuff people can use. it's a hard endeavor to do well alone, if you dont have a team of other experts who can help you put all the puzzle pieces together on how to deploy things the right way and also add pieces like redis or whatever... it's just a lot. it's hard to find where to get started. sqlite is the only solution that really by nature of what it is seems to champion the lonely developer, but the tradeoffs are big if you're trying to make something that should get used by many people.
So many times when trying to just go for simplicity with SQLite it takes me like one working day until I run up against enough annoyances to where resolving those is more work than setting up the "set up and forget" postgres instance.
Granted, this is for personal stuff... but "Postgres packaged for low maintenance" is present in a lot of OS package managers! Even for smaller data analysis work SQLite perf leads _loads_ to be desired (once had QGIS struggling with a sqlite DB... pg made everything mostly instant. Indices etc... but stuff I _couldn't easily get with sqlite_)
If SQLite works for you that's great, I do think it's worth it for people to _try_ to do simple pg setups to understand just how painful it is to use pg (for me: not that high)
1. Downtime doesn't matter. 2. Paying someone else (eg. AWS) to manage redundancy and fail-over.
It just feels crazy to me that Postgres still doesn't have a native HA story since I last battled with this well over a decade ago.
The big problem for me from running DB on Btrfs is that when I delete large dirs or files (100GB+), it locks disk system, and Db basically stop responding on any queries.
I am very surprised that FS which is considered prod grade having this issue..
At some point you end up with binary columns and custom encoded values, to save space by reducing row count. Kind of doing away with the benefits of a DB.
But it's perfect HN bait, really. The title is spicy enough that folks will comment without reading the article (more so than usual), and so it survives a bit longer before being flagged as slop.
I understand that reading the title and probably skimming the article makes it a good jumping off point for a comment thread. I do like the HN comments but I don't want it to be just some forum of curious tech folks, I want it to be a place I find interesting content too.
https://www.postgresql.org/docs/current/sql-createtable.html...
(I run a medium-sized Postgres deployment and like it, but I don't feel like it's a cost-effective solution to every database problem.)
PostgreSQL is good enough to get to medium sized with nearly every use case. Once you are there, you have the use case and the test data to test any alternative for it well, rather than trying to guess beforehand what you actually need.
The advice is basically "PostgreSQL is probably good enough for whatever you're building now, and you should only look for other solution once you are big enough that it stops being that"
btw, big fan of postgres :D
Tiger Data offers continuous aggs via hypertable but they need to be configured quite granularly and they're not super flexible. How are you all thinking about that when it comes to postgres and aggregations?
Redis is many times faster, so much that it doesn't seem comparable to me.
A lot of data you can get away with just caching in-mem on each node, but when you have many nodes there are valid cases where you really want that distributed cache.
Run benchmarks that show that, for your application under your expected best-case loads, using Redis for caching instead of PostgreSQL provides a meaningful improvement.
If it doesn't provide a meaningful improvement, stick with PostgreSQL.
Just use memcache for query cache if you have to. And only if you have to, because invalidation is hard. It's cheap, reliable, mature, fast, scalable, requires little understanding, has decent quality clients in most languages, is not stateful and available off the shelf in most cloud providers and works in-clusetr in kubernetes if you want to do it that way.
I can't find a use case for Redis that postgres or postgres+memcache isn't a simpler and/or superior solution.
Just to give you an idea how good memcache is, I think we had 9 billion requests across half a dozen nodes over a few years without a single process restart.
But As soon as you go outside Postgres you cannot guarantee consistent reads within a transaction.
That’s usually ok, but it’s worth bringing up.
I'd never advocate for a new oracle install. But, I'd likely defend an existing one. I've seen how effective pl/sql can be in complex environments. Rewriting all that sql just because "oracle man bad" (or whatever) is a huge fucking ask of any rational business owner.
I've had engineers want to talk about syncing it to MySQL using some custom plumbing so that they can build a reporting infra around their MySQL stack, but it's just another layer of complexity over having code just use Microsoft's reporting services.
I'll add, having finance people with Excel really like being able to pull data directly from MSSQL, they do not like hearing about a technican's python app.
Im also curious about benchmark results.
If you follow this advice naively, you might try to implement two or more of these other-kind-of-DB simulacra data models within the same Postgres instance.
And it’ll work, at first. Might even stay working if only one of the workloads ends up growing to a nontrivial size.
But at scale, these different-model workloads will likely contend with one-another, starving one-another of memory or disk-cache pages; or you’ll see an “always some little thing happening” workload causing a sibling “big once-in-a-while” workload to never be able to acquire table/index locks to do its job (or vice versa — the big workloads stalling the hot workloads); etc.
And even worse, you’ll be stuck when it comes to fixing this with instance-level tuning. You can only truly tune a given Postgres instance to behave well for one type-of-[scaled-]workload at a time. One workload-type might use fewer DB connections and depend for efficiency on them having a higher `work_mem` and `max_parallel_workers` each; while another workload-type might use many thousands of short-lived connections and depend on them having small `work_mem` so they’ll all fit.
But! The conclusion you should draw from being in this situation shouldn’t be “oh, so Postgres can’t handle these types of workloads.”
No; Postgres can handle each of these workloads just fine. It’s rather that your single monolithic do-everything Postgres instance, maybe won’t be able to handle this heterogeneous mix of workloads with very different resource and tuning requirements.
But that just means that you need more Postgres.
I.e., rather than adding a different type-of-component to your stack, you can just add another Postgres instance, tuned specifically to do that type of work.
Why do that, rather than adding a component explicitly for caching/key-values/documents/search/graphs/vectors/whatever?
Well, for all the reasons TFA outlines. This “Postgres tuned for X” instance will still be Postgres, and so you’ll still get all the advantages of being able to rely on a single query language, a single set of client libraries and tooling, a single coherent backup strategy, etc.
Where TFA’s “just use Postgres” in the sense of reusing your Postgres instance only scales if your DB is doing a bare minimum of that type of work, interpreting “just use Postgres” in the sense of adding a purpose-defined Postgres instance to your stack will scale nigh-on indefinitely. (To the point that, if you ever do end up needing what a purpose-built-for-that-workload datastore can give you, you’ll likely be swapping it out for an entire purpose-defined PG cluster by that point. And the effort will mostly serve the purpose of OpEx savings, rather than getting you anything cool.)
And, as a (really big) bonus of this approach, you only need to split PG this way where it matters, i.e. in production, at scale, at the point that the new workload-type is starting to cause problems/conflicts. Which means that, if you make your codebase(s) blind to where exactly these workloads live (e.g. by making them into separate DB connection pools configured by separate env-vars), then:
- in dev (and in CI, staging, etc), everything can default to happening on the one local PG instance. Which means bootstrapping a dev-env is just `brew install postgres`.
- and in prod, you don’t need to pre-build with new components just to serve your new need. No new Redis instance VM just to serve your so-far-tiny KV-storage needs. You start with your new workload-type sharing your “miscellaneous business layer” PG instance; and then, if and when it becomes a problem, you migrate it out.
yea this is me. postgres is actually insane for how much is offered at checks notes free.99.
_however_ we are probably due for like. I don't know a happy configurator type tool that has reasonable presets and a nice user friendly config tool that helps people get going without sidequesting for a year on devops/dbadmin expertise. that isn't even a favored outcome imo, you just get pretty lukewarm postgres-deployers who are probably missing a bunch of important settings/flags. my team mates would probably shit themselves in the face of postgres configs currently, they are absolute rats in the code but good and proper deployment of postgres is just a whole other career-arc they haven't journeyed and a _lot_ of organizations don't always have a devops/dbadmin type guy readily available any time you want to scrap together an app who's just going to wait for your signal to deploy for you. or said devops/dbadmin guy is just.. one guy and he's supporting 500 other things. not saying the absence/failing to scale teams with such personnel is right, it's just the reality and being up against workplace politics and making the case to convince orgs to hire a bigger team of devops/dbadmin guys involves a lot of shitty meetings and political prowess that is typically beyond an engineers set of capabilities, at least below the senior level. any engineer can figure out how to deploy postgres to something, but are they doing it in a way that makes an orgs security/infra guys happy? probably not. are they prepared to handle weird storage scenarios (log or temp space filling grinding server to a halt) and understand the weird and robust ways to manage a deployment? probably not.
Have you looked into it?
eg Python, react... very little OCaml, Haskell, etc.
I agree that managing lots of databases can be a pain in the ass, but trying to make Postgres do everything seems like a problem as well. A lot of these things are different things and trying to make Postgres do all of them seems like it will lead to similar if not worse outcomes than having separate dedicated services.
I understand that people were too overeager to jump on the MongoDB web scale nosql crap, but at this point I think there might have been an overcorrection. The problem with the nosql hype wasn't that they weren't using SQL, it's that they were shoehorning it everywhere, even in places where it wasn't a good fit for the job. Now this blog post is telling us to shoehorn Postgres everywhere, even if it isn't a good fit for the job...
I really like having some JSON storage because I don't know my schema up front all the time, and just shoving every possible piece of potentially useful metadata in there has (generally) not bit me, but not having that critical piece of metadata has been annoying (that field that should be NOT NULL is NULL because I can't populated it after the fact).
The argument, as in this blog, is that a single Postgres stack is simpler and reduces complexity. What’s often overlooked is the CAPEX and OPEX required to make Postgres work well for workloads it wasn’t designed for, at even reasonable scale. At Citus Data, we saw many customers with solid-sized teams of Postgres experts whose primary job was constant tuning, operating, and essentially babysitting the system to keep it performing at scale.
Side note, we’re seeing purpose-built technologies show up much earlier in a company’s lifecycle, likely accelerated by AI-driven use cases. At ClickHouse, many customers using Postgres replication are seed-stage companies that have grown extremely quickly. We pulled together some data on these trends here: https://clickhouse.com/blog/postgres-cdc-year-in-review-2025...
A better approach would be to embrace the integration of purpose-built technologies with Postgres, making it easier for users to get the best of both worlds, rather than making overgeneralized claims like “Postgres for everything” or “Just use Postgres.”
In other words, there are people and situations where it makes sense to use something else. But most people believing they're in that category are wrong.
I take it as meaning use Postgres until there's a reason not to. ie build for the scale / growth rate you have not "how will this handle the 100 million users I dream of." A simpler tech stack will be simpler to iterate on.
Oh no, not a company hiring a team of specialist in a core technology you need! What next, paying them a good wage? C'mon, it's so much better to get a bunch of random, excuse me, "specialized" SaaS tools that will _surely_ not lead to requiring five teams of specialists in random technologies that will eventually be discontinued once Google acquires the company running them.
OK but seriously, yeah sometimes "specialized" is good, though much less rarely than people pretend it to be. Having specialists ain't bad, and I'd say is better than telling a random developer to become a specialist in some cloud tech and pretending you didn't just end up turning a - hopefully decent - developer into a poor DBA. Not to mention that a small team of Postgres specialists can maintain a truly stupendous amount of Postgres.
I personally think reading manuals and tuning is a comparably low risk form of software development.
It would be awesome to have easy clustering directly built-in. Similar to MongoDB, where you tell the primary instance to use a replica set, then simply connect two secondaries to primary, done.
asdev•1h ago
oulipo2•1h ago
asdev•59m ago