{"slug": "postgresql", "name": "PostgreSQL", "category": "databases", "category_name": "Databases", "description": "Open-source object-relational database system with SQL, extensions, and ACID transactions.", "recommenders": 79, "commenters": 171, "warners": 5, "score": 87.879, "rising": 7.67, "first": "2025-11-02", "latest": "2026-10-24", "why": "HN commenters like PostgreSQL as a reliable default database that holds up at large scale and can also act as a queue, search engine or vector store, so teams run fewer services.", "why_is_quote": false, "has_verdict": true, "sentiment": {"recommend": 83, "neutral": 87, "compare": 7, "warn": 5}, "spark": [1, 3, 8, 7, 6, 4, 4, 7, 16, 21, 2, 4], "listed": true, "loved": ["All-in-one", "Reliability at scale"], "caveat": "Vacuum bloat", "short_quote": "I love Postgres. Im using it for majority of my career in IT. It never failed me, even on very big scale.", "icon": true, "domain": "postgresql.org", "github_repo": null, "official_url": "https://www.postgresql.org/", "pricing": "open source", "aliases": ["PostgreSQL"], "verdict": [{"text": "HN commenters like PostgreSQL as a reliable default database that holds up at large scale", "cites": [{"id": 790081632, "item_id": 49380102, "url": "https://news.ycombinator.com/item?id=49380102", "by": "pojzon", "date": "2026-08-20", "stance": "recommend", "quote": "I love Postgres. Im using it for majority of my career in IT. It never failed me, even on very big scale.", "excerpt": "Its not a meme. Postgres does all of those things good enough to be always considered the first pick. I love Postgres. Im using it for majority of my career in IT. It never failed me, even on very big scale. Amazing piece of software.", "context": "IT career", "use_case": "general-purpose database", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789728640, "item_id": 49358040, "url": "https://news.ycombinator.com/item?id=49358040", "by": "aurareturn", "date": "2026-08-19", "stance": "recommend", "quote": "It was surprisingly easy with a single large Postgres DB, a lot of caching, optimized tables and queries.", "excerpt": "HTTP traffic is different from run this CPU intensive pipeline service for 10 minutes and now increase the volume by 100x in a few months. I used to manage a popular app/website that had tens of billions of real user page views per month. It wasn't easy but it also wasn't hard. It was surprisingly easy with a single large Postgres DB, a lot of caching, optimized tables and queries.", "context": "managed a popular app/website with tens of billions of page views per month", "use_case": "high-traffic website backend", "switched_from": "", "story": "Incident with Github.com"}, {"id": 798107633, "item_id": 49881727, "url": "https://news.ycombinator.com/item?id=49881727", "by": "Imustaskforhelp", "date": "2026-09-28", "stance": "recommend", "quote": "postgresql is almost always good enough in my opinion", "excerpt": "Curious to know what does actually scale according to your opinion (if not postgres) and what is the scale that we are talking about when mentioning some of the largest databases ever built (I hope you can talk more about it!) There seems to be many many options at attempting/trying to scale postgresql, what are your opinions of them? Also It is my sort of opinion that you really have a good problem if postgresql isn", "context": "", "use_case": "general database", "switched_from": "", "story": "MongoDB CEO resigns to join Meta"}]}, {"text": " and can also act as a queue, search engine or vector store, so teams run fewer services.", "cites": [{"id": 789795152, "item_id": 49362197, "url": "https://news.ycombinator.com/item?id=49362197", "by": "molf", "date": "2026-08-19", "stance": "recommend", "quote": "In most of the applications we build or maintain we use PostgreSQL + cloud storage. That's it. And it works very well", "excerpt": "I don't think the point is that PostgreSQL is great for everything. But you may get by with a single piece of infrastructure instead of 7. In most of the applications we build or maintain we use PostgreSQL + cloud storage. That's it. And it works very well, also for: storing JSON, full text search, as a queue, as a vector database. Other software may be better at providing those features, but I'm extremely happy we o", "context": "builds and maintains applications", "use_case": "JSON, full text search, queue, vector DB", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 773029296, "item_id": 48314331, "url": "https://news.ycombinator.com/item?id=48314331", "by": "buremba", "date": "2026-05-28", "stance": "recommend", "quote": "All you need is Postgres until you scale into TBs of data.", "excerpt": "All you need is Postgres until you scale into TBs of data. We use Postgresql as a durable workflow engine, vector search, time-series data, BM25 search, OLTP/OLAP engine, and a queue. It's basically the only dependency we have for https://lobu.ai The main benefit is centralizing all the data in one place so we don't need to worry about copying data in between multiple systems. Once something becomes the bottleneck, y", "context": "", "use_case": "workflows, vector search, queue, OLTP/OLAP", "switched_from": "", "story": "Just Use Postgres for Durable Workflows"}, {"id": 780913088, "item_id": 48807068, "url": "https://news.ycombinator.com/item?id=48807068", "by": "wuliwong", "date": "2026-07-06", "stance": "recommend", "quote": "I love the flexibility and all-in-one abilities of Postgres for prototyping and making MVPs.", "excerpt": "For context, I am mainly talking about my personal projects, ideas I am trying out, MVPs/prototypes for potential new businesses, etc. I have started just using Postgres to back queues. It is simpler (although I have spun up new apps with Redis so many times it is only a small improvement) but more importantly it is cheaper. I really do try a lot of stuff out, so completely removing a infrastructure piece is a nice m", "context": "builds personal projects and MVPs", "use_case": "queues and prototypes", "switched_from": "Redis", "story": "You probably don't need another database"}]}, {"text": " The most common caveat is vacuum and dead-tuple bloat on update-heavy and queue workloads,", "cites": [{"id": 785851665, "item_id": 49115729, "url": "https://news.ycombinator.com/item?id=49115729", "by": "atombender", "date": "2026-07-30", "stance": "warn", "quote": "dead tuples start to accumulate due to Postgres' way of doing MVCC.", "excerpt": "A performance pitfall that isn't addressed in the DBOS article at all is the bloat problem: If you update or delete rows that you consume, dead tuples start to accumulate due to Postgres' way of doing MVCC. This is a serious problem because it affects the planner's ability to make good choices. Dead tuples are still indexed and the need to skip them isn't accounted for by the query planner, so a table with lots of de", "context": "", "use_case": "queue", "switched_from": "", "story": "Postgres Queues Actually Scale"}, {"id": 765131968, "item_id": 47820748, "url": "https://news.ycombinator.com/item?id=47820748", "by": "mind-blight", "date": "2026-04-18", "stance": "warn", "quote": "I love the idea of pg as a queue, but I'm a more skeptical of it after dealing with it in production", "excerpt": "The vacuum pressure is real. Using a system with the skip locked technique + polling caused massive DB perf issues as the queue depth grew. The query to see the current jobs in the queue ended up being the main performance bottleneck, which cause slower throughput, which caused a larger queue depth, which etc. Scaling the workers sometimes exacerbates the problem because you run into connection limits or polling hamm", "context": "", "use_case": "job queue", "switched_from": "", "story": "PgQue: Zero-Bloat Postgres Queue"}, {"id": 778670064, "item_id": 48666879, "url": "https://news.ycombinator.com/item?id=48666879", "by": "mikeocool", "date": "2026-06-24", "stance": "recommend", "quote": "I love Postgres.", "excerpt": "I love Postgres. I buy using it for many many things. I really don\u2019t understand why everyone insists that you should use it as a work/message queue. There are lots of purpose-built bullet proof queuing systems that are simple to setup and administer (or just use SQS). Your queue is likely to have very different access patterns than the rest of your data, and sticking it in Postgres means you\u2019re probably going to end ", "context": "", "use_case": "database", "switched_from": "", "story": "PostgreSQL Is Enough"}]}, {"text": " along with more setup and operational overhead than SQLite for small apps.", "cites": [{"id": 783256688, "item_id": 48953543, "url": "https://news.ycombinator.com/item?id=48953543", "by": "abrookewood", "date": "2026-07-17", "stance": "recommend", "quote": "Honestly, I love PostgreSQL, but now I have another server or service to run.", "excerpt": "Honestly, I love PostgreSQL, but now I have another server or service to run. SQLite is just a file and often, that is enough.", "context": "", "use_case": "", "switched_from": "", "story": "Learning a few things about running SQLite"}, {"id": 783240704, "item_id": 48952544, "url": "https://news.ycombinator.com/item?id=48952544", "by": "gnulinux", "date": "2026-07-17", "stance": "recommend", "quote": "I love postgres as much as the next person", "excerpt": "> run on postgresql with no overhead at all Citation needed. I love postgres as much as the next person, but it does have more overhead than Sqlite which is in an in-process db linked through compiled C code, it doesn't run as a separate server. Very significant difference that when you use Sqlite db, there is typically no db process other than your application logic, unless you implement the server yourself. If you ", "context": "", "use_case": "", "switched_from": "", "story": "Lobste.rs is now running on SQLite"}, {"id": 786025985, "item_id": 49126624, "url": "https://news.ycombinator.com/item?id=49126624", "by": "Imustaskforhelp", "date": "2026-07-31", "stance": "recommend", "quote": "both sqlite and postgres are awesome", "excerpt": "Yup its a really decent advice overall but I feel like there were some few use-cases I think where postgres made more sense but I found the initial setup to be slightly more complex than sqlite and oh I love both sqlite and postgres and was just thinking of merging somewhat all the things that I like about them haha but I get what you mean, both sqlite and postgres are awesome :)", "context": "", "use_case": "", "switched_from": "", "story": "Self-contained highly-portable Python distributions"}]}], "praise": [{"label": "All-in-one", "summary": "One Postgres instance can cover JSON, full-text search, queues, vectors and workflows, so there is less infrastructure to manage.", "quotes": [{"id": 789795152, "item_id": 49362197, "url": "https://news.ycombinator.com/item?id=49362197", "by": "molf", "date": "2026-08-19", "stance": "recommend", "quote": "In most of the applications we build or maintain we use PostgreSQL + cloud storage. That's it. And it works very well", "excerpt": "I don't think the point is that PostgreSQL is great for everything. But you may get by with a single piece of infrastructure instead of 7. In most of the applications we build or maintain we use PostgreSQL + cloud storage. That's it. And it works very well, also for: storing JSON, full text search, as a queue, as a vector database. Other software may be better at providing those features, but I'm extremely happy we o", "context": "builds and maintains applications", "use_case": "JSON, full text search, queue, vector DB", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 773029296, "item_id": 48314331, "url": "https://news.ycombinator.com/item?id=48314331", "by": "buremba", "date": "2026-05-28", "stance": "recommend", "quote": "All you need is Postgres until you scale into TBs of data.", "excerpt": "All you need is Postgres until you scale into TBs of data. We use Postgresql as a durable workflow engine, vector search, time-series data, BM25 search, OLTP/OLAP engine, and a queue. It's basically the only dependency we have for https://lobu.ai The main benefit is centralizing all the data in one place so we don't need to worry about copying data in between multiple systems. Once something becomes the bottleneck, y", "context": "", "use_case": "workflows, vector search, queue, OLTP/OLAP", "switched_from": "", "story": "Just Use Postgres for Durable Workflows"}, {"id": 780913088, "item_id": 48807068, "url": "https://news.ycombinator.com/item?id=48807068", "by": "wuliwong", "date": "2026-07-06", "stance": "recommend", "quote": "I love the flexibility and all-in-one abilities of Postgres for prototyping and making MVPs.", "excerpt": "For context, I am mainly talking about my personal projects, ideas I am trying out, MVPs/prototypes for potential new businesses, etc. I have started just using Postgres to back queues. It is simpler (although I have spun up new apps with Redis so many times it is only a small improvement) but more importantly it is cheaper. I really do try a lot of stuff out, so completely removing a infrastructure piece is a nice m", "context": "builds personal projects and MVPs", "use_case": "queues and prototypes", "switched_from": "Redis", "story": "You probably don't need another database"}]}, {"label": "Reliability at scale", "summary": "Users report it rarely fails and handles very large workloads with caching and tuned queries.", "quotes": [{"id": 790081632, "item_id": 49380102, "url": "https://news.ycombinator.com/item?id=49380102", "by": "pojzon", "date": "2026-08-20", "stance": "recommend", "quote": "I love Postgres. Im using it for majority of my career in IT. It never failed me, even on very big scale.", "excerpt": "Its not a meme. Postgres does all of those things good enough to be always considered the first pick. I love Postgres. Im using it for majority of my career in IT. It never failed me, even on very big scale. Amazing piece of software.", "context": "IT career", "use_case": "general-purpose database", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789728640, "item_id": 49358040, "url": "https://news.ycombinator.com/item?id=49358040", "by": "aurareturn", "date": "2026-08-19", "stance": "recommend", "quote": "It was surprisingly easy with a single large Postgres DB, a lot of caching, optimized tables and queries.", "excerpt": "HTTP traffic is different from run this CPU intensive pipeline service for 10 minutes and now increase the volume by 100x in a few months. I used to manage a popular app/website that had tens of billions of real user page views per month. It wasn't easy but it also wasn't hard. It was surprisingly easy with a single large Postgres DB, a lot of caching, optimized tables and queries.", "context": "managed a popular app/website with tens of billions of page views per month", "use_case": "high-traffic website backend", "switched_from": "", "story": "Incident with Github.com"}, {"id": 787495200, "item_id": 49218450, "url": "https://news.ycombinator.com/item?id=49218450", "by": "hmokiguess", "date": "2026-08-07", "stance": "recommend", "quote": "We use Postgres because it\u2019s fantastic at the scale and problems it solve", "excerpt": "I don\u2019t understand. It\u2019s not like we don\u2019t already have faster alternatives, don\u2019t we have things like k and kdb that are many orders of magnitude faster even than this? We use Postgres because it\u2019s fantastic at the scale and problems it solve, if you have an extremely critical system where raw speed is at the core of everything and you\u2019re dealing with petascale then maybe you\u2019re bringing a solution you like to a pro", "context": "", "use_case": "general database", "switched_from": "", "story": "Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD"}]}, {"label": "Job queues", "summary": "Some teams find Postgres-backed queues simple and dependable, using SKIP LOCKED and advisory locks.", "quotes": [{"id": 789906465, "item_id": 49369154, "url": "https://news.ycombinator.com/item?id=49369154", "by": "throwitaway222", "date": "2026-08-19", "stance": "recommend", "quote": "just worked great for us on Postgres", "excerpt": "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", "context": "", "use_case": "job queue", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 773018656, "item_id": 48313666, "url": "https://news.ycombinator.com/item?id=48313666", "by": "sgt", "date": "2026-05-28", "stance": "recommend", "quote": "Continuously amazed by what you can do with few tools, as long as Postgres is a part of your toolkit.", "excerpt": "Continuously amazed by what you can do with few tools, as long as Postgres is a part of your toolkit. I recently developed a distributed queue and it works really great - benchmarks great too, with no race conditions or conflicts. I used SKIP LOCKED so that workers can compete safely. You can also have multiple workers across nodes avoid conflict by using session wide mutexes i.e. pg advisory lock.", "context": "", "use_case": "distributed queue with SKIP LOCKED", "switched_from": "", "story": "Just Use Postgres for Durable Workflows"}, {"id": 774637600, "item_id": 48414850, "url": "https://news.ycombinator.com/item?id=48414850", "by": "thibaut_barrere", "date": "2026-06-05", "stance": "recommend", "quote": "We use Postgres for that on https://transport.data.gouv.fr (Elixir app which does a fair bit of processing), and it helps.", "excerpt": "You can have well-integrated applicative workflows (eg: progress report on a permalink in your front end app), app-restart-proof resumable workflows, and it avoids adding an extra piece of infrastructure. We use Postgres for that on https://transport.data.gouv.fr (Elixir app which does a fair bit of processing), and it helps. Not familiar yet with pg_durable though, but I have used or implemented similar solutions an", "context": "", "use_case": "durable workflows", "switched_from": "", "story": "pg_durable: Microsoft open sources in-database durable execution"}]}, {"label": "Rich features", "summary": "Commenters value its strict types, functions, DISTINCT ON, Row Level Security and built-in auth.", "quotes": [{"id": 789134816, "item_id": 49320926, "url": "https://news.ycombinator.com/item?id=49320926", "by": "tyre", "date": "2026-08-16", "stance": "recommend", "quote": "I\u2019m very comfortable in Postgres and the setup cost is basically zero (like SQLite) because Claude does it.", "excerpt": "All of my personal apps use Postgres because: - types are lovely. We love types. SQLite\u2019s default of non-strict typing is, to me, bananas. - SELECT DISTINCT ON is my ride-or-die - most importantly, I\u2019m very comfortable in Postgres and the setup cost is basically zero (like SQLite) because Claude does it.", "context": "", "use_case": "personal apps", "switched_from": "", "story": "Does anyone run Postgres without PgBouncer?"}, {"id": 800797936, "item_id": 50049871, "url": "https://news.ycombinator.com/item?id=50049871", "by": "somat", "date": "2026-10-12", "stance": "recommend", "quote": "My normal mode of operation is via postgres(I like the functions better than sqlite)", "excerpt": "It's not even that good for switching to different engines. My normal mode of operation is via postgres(I like the functions better than sqlite) But for a recent little program thought it would be nice to have it a little more self contained and allow for a sqlite db if wanted. Ignoring the the sql differences(Remember, I use postgres for it's functions, so there were many) sqlite uses a different parameter style(I e", "context": "", "use_case": "primary database", "switched_from": "", "story": "apsw: Another Python SQLite Wrapper"}, {"id": 788790816, "item_id": 49299426, "url": "https://news.ycombinator.com/item?id=49299426", "by": "insanitybit", "date": "2026-08-14", "stance": "recommend", "quote": "We use Postgres for a lot of data. We've used it a ton at the company and have a lot of expertise.", "excerpt": "I don't have a technology stack. Do you just mean what am I using for current projects? At work we use Rust primarily for services. It was chosen because we're doing a lot of low level and performance sensitive work. The risk we discussed most was devs not knowing the language, which we decided to hedge against in various ways and accepted that risk. We use Postgres for a lot of data. We've used it a ton at the compa", "context": "works at a company with Rust services", "use_case": "relational data, multitenancy", "switched_from": "", "story": "Choose Boring Technology (2015)"}]}, {"label": "Server default", "summary": "Often recommended over SQLite when a server app needs something more robust.", "quotes": [{"id": 791904883, "item_id": 49494055, "url": "https://news.ycombinator.com/item?id=49494055", "by": "Kuyawa", "date": "2026-08-29", "stance": "recommend", "quote": "or postgresql if something more robust on your server", "excerpt": "I use a 1MB Rust shell with a webview (wry and winit). It works wonders Drop a SQLite db if you want a quick portable app, or postgresql if something more robust on your server. Tell your AI of choice [2] to create a TODO rust app [1] in html, css and js using wry and winit and you'll see what I mean, a thing of beauty [1] https://github.com/kuyawa/todo-rust [2] https://github.com/kuyawa/todo-rust/blob/main/prompt.tx", "context": "", "use_case": "server database", "switched_from": "", "story": "Ask HN: Any true alternatives to electron JavaScript?"}, {"id": 786170513, "item_id": 49135657, "url": "https://news.ycombinator.com/item?id=49135657", "by": "bastawhiz", "date": "2026-08-01", "stance": "recommend", "quote": "I'm the sort of person who leans on Postgres instead of sqlite", "excerpt": "I love this and agree with it so strongly. But I'm also shaken to my core that there's a $30/mo Neon bill for personal software. Even if it's being used for \"slightly larger projects\" as well that's a ton of overkill for what seems like mostly read only data. I'm the sort of person who leans on Postgres instead of sqlite, but I'll put aside the sqlite argument for now because the fruit is so low hanging here. These u", "context": "", "use_case": "database", "switched_from": "", "story": "Software for One"}, {"id": 789802113, "item_id": 49362632, "url": "https://news.ycombinator.com/item?id=49362632", "by": "thatwasunusual", "date": "2026-08-19", "stance": "recommend", "quote": "Both are amazing technologies.", "excerpt": "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.", "context": ".NET developer", "use_case": "production database", "switched_from": "", "story": "PostgreSQL for Everything"}]}, {"label": "Replication & copies", "summary": "Streaming replication and fast copy-on-write database cloning work well in practice.", "quotes": [{"id": 781068323, "item_id": 48816770, "url": "https://news.ycombinator.com/item?id=48816770", "by": "pqdbr", "date": "2026-07-07", "stance": "recommend", "quote": "reliable, tested, fault tolerant postgres with streaming replication", "excerpt": "Claude Code has been a blessing for all our devops work. We use baremetal servers and now have reliable, tested, fault tolerant postgres with streaming replication and barman for backups configured and running, with less than a second of replication lag, including a S3 redundant backup with < 1 minute of data loss (archive_timeout=60s) with S3 object-lock set up in compliance mode (so even the ransonware scenario is ", "context": "Runs baremetal servers", "use_case": "self-hosted database", "switched_from": "", "story": "PostgreSQL Benchmark: AWS RDS vs. Self-Hosted on Hetzner (2026)"}, {"id": 784895409, "item_id": 49055963, "url": "https://news.ycombinator.com/item?id=49055963", "by": "faangguyindia", "date": "2026-07-26", "stance": "recommend", "quote": "For larger apps i use postgres (why? replication is easy using pgfailover", "excerpt": "I mostly use Go + SQLite for all the things I used to use Rails, JavaScript, or Python for. I find python django wastes too much resources, just look at memory usage. One of my web app backend (go) is serving approx 100 req/s right now and i look at pprof i see it's not bottlenecked by CPU but mostly IO and i love this. Writing concurrent code in Go is easy, the code i wrote 10yrs ago still compiles with no issue! Th", "context": "", "use_case": "larger apps", "switched_from": "", "story": "Some more things about Django I've been enjoying"}, {"id": 786241184, "item_id": 49140074, "url": "https://news.ycombinator.com/item?id=49140074", "by": "spellboots", "date": "2026-08-01", "stance": "recommend", "quote": "This copies arbitrarily sized DBs sub-second - I use it on dbs larger than 1TB regularly", "excerpt": "Many people are unaware of a relatively recent method that allows almost instant copies of postgres databases that I use very heavily: CREATE DATABASE new_db TEMPLATE templatedb STRATEGY FILE_COPY Combined with set file_copy_method = 'clone' This copies arbitrarily sized DBs sub-second - I use it on dbs larger than 1TB regularly - and has the advantage of being copy-on-write - the new db doesn't take up any extra dis", "context": "", "use_case": "instant database cloning", "switched_from": "", "story": "Pgtestdb's template cloning approach to testing is fast"}]}], "caveats": [{"label": "Vacuum bloat", "summary": "Dead tuples from MVCC can degrade performance and need aggressive autovacuum tuning.", "quotes": [{"id": 785851665, "item_id": 49115729, "url": "https://news.ycombinator.com/item?id=49115729", "by": "atombender", "date": "2026-07-30", "stance": "warn", "quote": "dead tuples start to accumulate due to Postgres' way of doing MVCC.", "excerpt": "A performance pitfall that isn't addressed in the DBOS article at all is the bloat problem: If you update or delete rows that you consume, dead tuples start to accumulate due to Postgres' way of doing MVCC. This is a serious problem because it affects the planner's ability to make good choices. Dead tuples are still indexed and the need to skip them isn't accounted for by the query planner, so a table with lots of de", "context": "", "use_case": "queue", "switched_from": "", "story": "Postgres Queues Actually Scale"}, {"id": 765131968, "item_id": 47820748, "url": "https://news.ycombinator.com/item?id=47820748", "by": "mind-blight", "date": "2026-04-18", "stance": "warn", "quote": "I love the idea of pg as a queue, but I'm a more skeptical of it after dealing with it in production", "excerpt": "The vacuum pressure is real. Using a system with the skip locked technique + polling caused massive DB perf issues as the queue depth grew. The query to see the current jobs in the queue ended up being the main performance bottleneck, which cause slower throughput, which caused a larger queue depth, which etc. Scaling the workers sometimes exacerbates the problem because you run into connection limits or polling hamm", "context": "", "use_case": "job queue", "switched_from": "", "story": "PgQue: Zero-Bloat Postgres Queue"}, {"id": 789790625, "item_id": 49361914, "url": "https://news.ycombinator.com/item?id=49361914", "by": "idoubtit", "date": "2026-08-19", "stance": "warn", "quote": "hide the Postgres limitations?", "excerpt": "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 ", "context": "", "use_case": "", "switched_from": "", "story": "PostgreSQL for Everything"}]}, {"label": "Queue limits", "summary": "Some warn that queue workloads strain the database as queue depth grows, and that purpose-built queues may fit better.", "quotes": [{"id": 765131968, "item_id": 47820748, "url": "https://news.ycombinator.com/item?id=47820748", "by": "mind-blight", "date": "2026-04-18", "stance": "warn", "quote": "I love the idea of pg as a queue, but I'm a more skeptical of it after dealing with it in production", "excerpt": "The vacuum pressure is real. Using a system with the skip locked technique + polling caused massive DB perf issues as the queue depth grew. The query to see the current jobs in the queue ended up being the main performance bottleneck, which cause slower throughput, which caused a larger queue depth, which etc. Scaling the workers sometimes exacerbates the problem because you run into connection limits or polling hamm", "context": "", "use_case": "job queue", "switched_from": "", "story": "PgQue: Zero-Bloat Postgres Queue"}, {"id": 778670064, "item_id": 48666879, "url": "https://news.ycombinator.com/item?id=48666879", "by": "mikeocool", "date": "2026-06-24", "stance": "recommend", "quote": "I love Postgres.", "excerpt": "I love Postgres. I buy using it for many many things. I really don\u2019t understand why everyone insists that you should use it as a work/message queue. There are lots of purpose-built bullet proof queuing systems that are simple to setup and administer (or just use SQS). Your queue is likely to have very different access patterns than the rest of your data, and sticking it in Postgres means you\u2019re probably going to end ", "context": "", "use_case": "database", "switched_from": "", "story": "PostgreSQL Is Enough"}]}, {"label": "Overhead vs SQLite", "summary": "It is a separate server to run and is harder to set up than an in-process SQLite file.", "quotes": [{"id": 783256688, "item_id": 48953543, "url": "https://news.ycombinator.com/item?id=48953543", "by": "abrookewood", "date": "2026-07-17", "stance": "recommend", "quote": "Honestly, I love PostgreSQL, but now I have another server or service to run.", "excerpt": "Honestly, I love PostgreSQL, but now I have another server or service to run. SQLite is just a file and often, that is enough.", "context": "", "use_case": "", "switched_from": "", "story": "Learning a few things about running SQLite"}, {"id": 783240704, "item_id": 48952544, "url": "https://news.ycombinator.com/item?id=48952544", "by": "gnulinux", "date": "2026-07-17", "stance": "recommend", "quote": "I love postgres as much as the next person", "excerpt": "> run on postgresql with no overhead at all Citation needed. I love postgres as much as the next person, but it does have more overhead than Sqlite which is in an in-process db linked through compiled C code, it doesn't run as a separate server. Very significant difference that when you use Sqlite db, there is typically no db process other than your application logic, unless you implement the server yourself. If you ", "context": "", "use_case": "", "switched_from": "", "story": "Lobste.rs is now running on SQLite"}, {"id": 786025985, "item_id": 49126624, "url": "https://news.ycombinator.com/item?id=49126624", "by": "Imustaskforhelp", "date": "2026-07-31", "stance": "recommend", "quote": "both sqlite and postgres are awesome", "excerpt": "Yup its a really decent advice overall but I feel like there were some few use-cases I think where postgres made more sense but I found the initial setup to be slightly more complex than sqlite and oh I love both sqlite and postgres and was just thinking of merging somewhat all the things that I like about them haha but I get what you mean, both sqlite and postgres are awesome :)", "context": "", "use_case": "", "switched_from": "", "story": "Self-contained highly-portable Python distributions"}]}, {"label": "Everything-in-Postgres", "summary": "Using it for everything can add more complexity than tailored tools like Redis.", "quotes": [{"id": 780908032, "item_id": 48806752, "url": "https://news.ycombinator.com/item?id=48806752", "by": "ubercore", "date": "2026-07-06", "stance": "recommend", "quote": "I love postgres, but the complexity of using it for everything starts to get pretty high", "excerpt": "I love postgres, but the complexity of using it for everything starts to get pretty high, compared to more tailor-suited tools. We should probably use it for _more_, in general, but the cost of \"everything in postgres\" is generally higher than I see acknowledged in articles like these.", "context": "", "use_case": "general database", "switched_from": "", "story": "You probably don't need another database"}, {"id": 780909392, "item_id": 48806837, "url": "https://news.ycombinator.com/item?id=48806837", "by": "JsonDemWitOster", "date": "2026-07-06", "stance": "recommend", "quote": "I love Postgres as a DB but, really, this is ridiculous.", "excerpt": "I'll do you one better: do you really need Postgres and all these extensions when you already have a filesystem? > only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative I love Postgres as a DB but, really, this is ridiculous. No doubt these extensions can do the job well-enough but you might as well invest in learning the right tool for t", "context": "", "use_case": "relational database", "switched_from": "", "story": "You probably don't need another database"}, {"id": 780905536, "item_id": 48806596, "url": "https://news.ycombinator.com/item?id=48806596", "by": "dpc10", "date": "2026-07-06", "stance": "recommend", "quote": "I love Postgres, and I agree with the general sentiment.", "excerpt": "I love Postgres, and I agree with the general sentiment. But I read the (growing) genre of \"use Postgres for everything\" articles and they imply a difficulty in running other software that I just don't see. I'm thinking of Redis in particular. If you're using it as incredibly fast but not critical storage, it's trivial to set up and it ~never crashes or requires maintenance. It creates no headaches, and in exchange g", "context": "", "use_case": "general database", "switched_from": "", "story": "You probably don't need another database"}]}, {"label": "Analytics speed", "summary": "Heavy OLAP or event-volume queries can be slow, so some pair it with ClickHouse.", "quotes": [{"id": 789836752, "item_id": 49364797, "url": "https://news.ycombinator.com/item?id=49364797", "by": "rgbrgb", "date": "2026-08-19", "stance": "recommend", "quote": "i'm still a postgres maximalist (worker queues still in pg [1])", "excerpt": "i love postgresql but once we added ai-generated dashboard to our homegrown analytics tool [0] some of the crazy (amazing) dashboards that the ops team was building began accumulating horrendously slow db queries. I considered dynamically adding indexes or alerting around postgres slow queries but also quickly prototyped mirroring the postgres data in clickhouse. At first could not believe how fast clickhouse was on ", "context": "", "use_case": "primary database and worker queues", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 781442834, "item_id": 48840177, "url": "https://news.ycombinator.com/item?id=48840177", "by": "BajajScooter", "date": "2026-07-08", "stance": "recommend", "quote": "Traditional databases(mysql, postgres) are perfect for transactional data.", "excerpt": "Traditional databases(mysql, postgres) are perfect for transactional data. users, products, orders and the like. but they aren't made for tracking events which is typically huge volume. that's why we used clickhouse db here which scales to billions of events easily. We also have sdks that you can use in your app to publish the events to our services. You can also query these events on our app, create trends, funnels,", "context": "", "use_case": "transactional data", "switched_from": "", "story": "Show HN: Pug.sh \u2013 open-source product analytics"}, {"id": 787507024, "item_id": 49219189, "url": "https://news.ycombinator.com/item?id=49219189", "by": "repsilat", "date": "2026-08-07", "stance": "recommend", "quote": "Postgres is amazing.", "excerpt": "Faster is better than slower. Postgres is amazing. When I use Sqlite I miss many of its upsides--better data migrations and better concurrency being two. But queries are not free, and sometimes are slower than I'd like even with the right indexes. And for OLAP-like queries like the one in TFA you might say \"well, just don't use postgres for that,\" but wouldn't it be better if you could? If you could use one database ", "context": "", "use_case": "general database", "switched_from": "", "story": "Making Postgres 300x faster for analytics: batching, operator fusion, and SIMD"}]}, {"label": "Ops effort", "summary": "Upgrades and tuning take real time investment.", "quotes": [{"id": 793631136, "item_id": 49601946, "url": "https://news.ycombinator.com/item?id=49601946", "by": "sysashi", "date": "2026-09-07", "stance": "recommend", "quote": "Annual postgres upgrades are always exciting (features) and terrifying (ops)", "excerpt": "`on conflict do select` and eager aggregation are the most notable for me, I use upserts and joins like that all the time. Annual postgres upgrades are always exciting (features) and terrifying (ops) :D (not that something can go wrong, I just feel anxiety hehe)", "context": "", "use_case": "upserts and joins", "switched_from": "", "story": "PostgreSQL 19 Interactive Tour"}, {"id": 784293648, "item_id": 49018353, "url": "https://news.ycombinator.com/item?id=49018353", "by": "lbriner", "date": "2026-07-23", "stance": "recommend", "quote": "I love postgres but it is not a toy and it takes investment of time.", "excerpt": "This guide is nicely formatted and very helpful but I think the comments prove that all it has done is taken a subset of the information from the manual and decided that \"these parts are important\" whereas the comments then unhelpfully point out, \"yes but also this\", \"and this\". There is no line that says X is important for a startup and Y isn't, it is mostly a matter of degree. Instead, what the guide has done altho", "context": "", "use_case": "database", "switched_from": "", "story": "The startup's Postgres survival guide"}]}], "who": [{"by": "caivi", "context": "AI-powered forward engineer looking for work", "url": "https://news.ycombinator.com/item?id=50081293", "date": "2026-10-14"}, {"by": "assimpleaspossi", "context": "web dev company owner for 22 years", "url": "https://news.ycombinator.com/item?id=50062128", "date": "2026-10-12"}, {"by": "jdboyd", "context": "runs a $5 VPS", "url": "https://news.ycombinator.com/item?id=49990355", "date": "2026-10-07"}, {"by": "curioustinkerer", "context": "Python backend engineer, 7+ years", "url": "https://news.ycombinator.com/item?id=49989699", "date": "2026-10-07"}, {"by": "joaokwanza", "context": "senior backend engineer", "url": "https://news.ycombinator.com/item?id=49986323", "date": "2026-10-07"}, {"by": "abumsoo", "context": "full stack engineer", "url": "https://news.ycombinator.com/item?id=49926303", "date": "2026-10-01"}, {"by": "36f", "context": "back end / full stack engineer job seeker", "url": "https://news.ycombinator.com/item?id=49924864", "date": "2026-10-01"}, {"by": "stakent", "context": "senior systems engineer seeking work", "url": "https://news.ycombinator.com/item?id=49922575", "date": "2026-10-01"}, {"by": "supz_k", "context": "works at HYVOR", "url": "https://news.ycombinator.com/item?id=49613489", "date": "2026-09-08"}, {"by": "frankheikens", "context": "20+ years PostgreSQL experience", "url": "https://news.ycombinator.com/item?id=49605188", "date": "2026-09-08"}, {"by": "pojzon", "context": "IT career", "url": "https://news.ycombinator.com/item?id=49380102", "date": "2026-08-20"}, {"by": "robomartin", "context": "designed and built industrial test robotic cell", "url": "https://news.ycombinator.com/item?id=49369756", "date": "2026-08-19"}], "tags": ["for web apps", "for job queues", "for prototypes and MVPs", "self-hostable", "for multitenant apps"], "use_cases": ["database", "general database", "backend database", "application database", "production database", "primary database"], "compared": [{"slug": "sqlite", "name": "SQLite", "co": 38, "switched_from": 0, "switched_to": 3}, {"slug": "mysql", "name": "MySQL", "co": 18, "switched_from": 0, "switched_to": 1}, {"slug": "redis", "name": "Redis", "co": 17, "switched_from": 1, "switched_to": 0}, {"slug": "clickhouse", "name": "ClickHouse", "co": 13, "switched_from": 0, "switched_to": 3}, {"slug": "fastapi", "name": "FastAPI", "co": 12, "switched_from": 0, "switched_to": 0}, {"slug": "react", "name": "React", "co": 12, "switched_from": 0, "switched_to": 0}, {"slug": "next-js", "name": "Next.js", "co": 10, "switched_from": 0, "switched_to": 0}, {"slug": "claude", "name": "Claude", "co": 10, "switched_from": 0, "switched_to": 0}], "makers": [{"id": 780404288, "item_id": 48775268, "url": "https://news.ycombinator.com/item?id=48775268", "by": "ozgune", "date": "2026-07-03", "stance": "recommend", "quote": "For Ubicloud as a managed Postgres provider, we use strict memory overcommit.", "excerpt": "(Ozgun from Ubicloud) I agree with the blog post's technical contents, but I feel we came across too strong in the title. For Ubicloud as a managed Postgres provider, we use strict memory overcommit. Our experience with operating Postgres at scale taught us that it's better to enable this than going with the defaults. However, I can see many other scenarios, where using strict memory overcommit would have unanticipat", "context": "works at Ubicloud, managed Postgres provider", "use_case": "managed Postgres", "switched_from": "", "story": "PostgreSQL and the OOM Killer: Why You Must Use Strict Memory Overcommit"}, {"id": 776140000, "item_id": 48508750, "url": "https://news.ycombinator.com/item?id=48508750", "by": "pjungwir", "date": "2026-06-12", "stance": "recommend", "quote": "Hey I worked on this!", "excerpt": "Hey I worked on this! Thank you to everyone here saying they are excited about it. I often hear doubts that anyone wants this. Perhaps that's why vendors have been so slow to add it. We are still missing system time, but if no one else wants to work on it, I hope to tackle that soon. I have a lot of other ideas for improvement beyond SQL:2011, too. Here is a talk I gave last month about my personal roadmap: https://i", "context": "contributor to Postgres 19 temporal features", "use_case": "temporal database features", "switched_from": "", "story": "Looking Forward to Postgres 19: It's About Time"}, {"id": 735237441, "item_id": 45952340, "url": "https://news.ycombinator.com/item?id=45952340", "by": "JoelJacobson", "date": "2025-11-17", "stance": "neutral", "quote": "fix the scalability issues in core PostgreSQL, so that's what I'm currently working on.", "excerpt": "In the linked \"Optimize LISTEN/NOTIFY\" pgsql-hackers, I've shared a lot of benchmark results for different workloads, which also include results on how PostgreSQL currently works (this is \"master\" in the benchmark results), that can help you better understand the expectations for different workloads. The work-around solution we used at Trustly (a company I co-founded), is a component named `allas` that a colleague of", "context": "co-founder of Trustly", "use_case": "database", "switched_from": "", "story": "Listen to Database Changes Through the Postgres WAL"}], "threads": [{"url": "https://news.ycombinator.com/item?id=49361279", "title": "PostgreSQL for Everything", "mentions": 12}, {"url": "https://news.ycombinator.com/item?id=49922568", "title": "Ask HN: Who wants to be hired? (October 2026)", "mentions": 6}, {"url": "https://news.ycombinator.com/item?id=48805564", "title": "You probably don't need another database", "mentions": 5}, {"url": "https://news.ycombinator.com/item?id=48666433", "title": "PostgreSQL Is Enough", "mentions": 5}, {"url": "https://news.ycombinator.com/item?id=49156682", "title": "Ask HN: Who wants to be hired? (August 2026)", "mentions": 4}, {"url": "https://news.ycombinator.com/item?id=49277952", "title": "Does anyone run Postgres without PgBouncer?", "mentions": 3}], "sentiment_by_month": {"2025-11": {"neutral": 3, "compare": 2, "recommend": 1}, "2025-12": {"neutral": 5, "recommend": 3, "warn": 1}, "2026-01": {"neutral": 10, "recommend": 8}, "2026-02": {"neutral": 5, "recommend": 7}, "2026-03": {"recommend": 6, "neutral": 3}, "2026-04": {"neutral": 5, "recommend": 4, "warn": 1}, "2026-05": {"neutral": 4, "recommend": 4, "warn": 1}, "2026-06": {"recommend": 7, "neutral": 10}, "2026-07": {"neutral": 10, "recommend": 16, "compare": 3, "warn": 1}, "2026-08": {"recommend": 21, "neutral": 11, "warn": 1}, "2026-09": {"compare": 2, "neutral": 9, "recommend": 2}, "2026-10": {"neutral": 12, "recommend": 4}}, "quotes": [{"id": 803536257, "item_id": 50221016, "url": "https://news.ycombinator.com/item?id=50221016", "by": "cpburns2009", "date": "2026-10-24", "stance": "neutral", "quote": "I convert it to UUID before storing in PostgreSQL.", "excerpt": "ULID is what I use. I convert it to UUID before storing in PostgreSQL. Technically it's an invalid serialization but it works. The system predates UUIDv7. I also like ULID's shorter representation.", "context": "", "use_case": "storing IDs", "switched_from": "", "story": "UUIDv7: Timestamps aren\u2019t time-ordered and other oddities"}, {"id": 803457810, "item_id": 50216113, "url": "https://news.ycombinator.com/item?id=50216113", "by": "rcoder", "date": "2026-10-23", "stance": "neutral", "quote": "a Postgres table can store any of the versions in the same column type", "excerpt": "If you really need monotonic, secure/unguessable IDs, there are options like CUID2 (github.com/paralleldrive/cuid2). Older designs like ULIDs (https://github.com/ulid/spec) and Snowflake IDs (https://en.wikipedia.org/wiki/Snowflake_ID) have similar properties to UUIDv7, and potentially some advantages w.r.t. length/encoding/runtime cost/etc. But UUIDv7 has one key advantage none of those do: you can store them in a U", "context": "", "use_case": "storing UUIDs", "switched_from": "", "story": "UUIDv7: Timestamps aren\u2019t time-ordered and other oddities"}, {"id": 803309873, "item_id": 50206867, "url": "https://news.ycombinator.com/item?id=50206867", "by": "coldtea", "date": "2026-10-23", "stance": "neutral", "quote": "Same reason a Postgres root can delete tables of other users.", "excerpt": ">Why doesn't docker respect unix filesystem permissions? I use docker on a shared server, i can delete docker images of other users. This is bonkers. Same reason a Postgres root can delete tables of other users. It could, but it would be a shim on top of Docker to respect them. Docker is a service daemon running as root, and the images of other users are just entries created by the other users in its registry, not se", "context": "", "use_case": "analogy for permissions", "switched_from": "", "story": "Docker is weird"}, {"id": 802677570, "item_id": 50167348, "url": "https://news.ycombinator.com/item?id=50167348", "by": "BajajScooter", "date": "2026-10-20", "stance": "neutral", "quote": "built using go, nats, clickhouse, postgres", "excerpt": "built using go, nats, clickhouse, postgres; goal is to make it easy to self host github: https://github.com/pug-sh/pug demo(no sign up needed): https://app.pug.sh/demo", "context": "", "use_case": "application database", "switched_from": "", "story": "Show HN: Pug \u2013 open-source product analytics"}, {"id": 802421201, "item_id": 50151325, "url": "https://news.ycombinator.com/item?id=50151325", "by": "CharlieDigital", "date": "2026-10-19", "stance": "neutral", "quote": "I run my backend on Postgres with partitioned tables.", "excerpt": "If you are using a Datadog, Langfuse, Langchain, or other OTEL target, you do nothing. Just query it. Build alerts, dashboards, and datasets; whatever you normally do with your OTEL collector. A forward OTEL collector deployment is still useful for filtering but the Datadog Agent, for example, already has buffering and filtering built into it. If you want to deploy your own collector and write your own handler (e.g. ", "context": "", "use_case": "telemetry backend", "switched_from": "", "story": "If you don't run your own LLM proxy, how do you know whats going on?"}, {"id": 801461441, "item_id": 50091340, "url": "https://news.ycombinator.com/item?id=50091340", "by": "pak9rabid", "date": "2026-10-14", "stance": "neutral", "quote": "It's a great addition to an existing Postgres database as it has very tight integration with it's native Postgres extension", "excerpt": "DuckDB is amazing. I swapped out some data analytics processing that was originally implemented with Python & Postgres to DuckDB and have been immensely pleased with the outcome. Stuff that would take 6+ hours to do with Python/Postgres now takes me around half an hour to complete. It's a great addition to an existing Postgres database as it has very tight integration with it's native Postgres extension, which allows", "context": "", "use_case": "existing database paired with DuckDB", "switched_from": "", "story": "Same Job, Two Engines: InnoDB and Iceberg Internals"}, {"id": 801300693, "item_id": 50081293, "url": "https://news.ycombinator.com/item?id=50081293", "by": "caivi", "date": "2026-10-14", "stance": "neutral", "quote": "TypeScript, Ansible, Postgres, Supabase/Neon/Render", "excerpt": "Location: Minneapolis, MN, USA Remote: Yes Willing to relocate: No Technologies: Opencode / Codex / Jcode, Tmux, Docker, Python, Node, TypeScript, Ansible, Postgres, Supabase/Neon/Render, automated CI / CD test pipelines, Sentry, FastAPI, Express/Hono R\u00e9sum\u00e9/CV: https://drive.google.com/file/d/1swpa5LInVdPEtjhhwxFWGsge8K5... Email: christopherisler1@gmail.com Portfolio: https://github.com/chrisisler - AI-powered forw", "context": "AI-powered forward engineer looking for work", "use_case": "", "switched_from": "", "story": "Ask HN: Who wants to be hired? (October 2026)"}, {"id": 800994049, "item_id": 50062128, "url": "https://news.ycombinator.com/item?id=50062128", "by": "assimpleaspossi", "date": "2026-10-12", "stance": "recommend", "quote": "All in C, fastcgi, FreeBSD, postgresql and h2o-server", "excerpt": "I started a web dev company 22 years ago after developing an online menu ordering system for a restaurant I owned. I, then we, did pretty much the same thing as talked about in the posting but we used fastcgi. I started with C because I knew C. That was my real job. It ran so well, the franchise bought the software from me--and then devolved it to all the Microsoft stuff and had issues upon issues from then on out. T", "context": "web dev company owner for 22 years", "use_case": "database for ordering sites", "switched_from": "", "story": "A Modern Web App in C"}, {"id": 800797936, "item_id": 50049871, "url": "https://news.ycombinator.com/item?id=50049871", "by": "somat", "date": "2026-10-12", "stance": "recommend", "quote": "My normal mode of operation is via postgres(I like the functions better than sqlite)", "excerpt": "It's not even that good for switching to different engines. My normal mode of operation is via postgres(I like the functions better than sqlite) But for a recent little program thought it would be nice to have it a little more self contained and allow for a sqlite db if wanted. Ignoring the the sql differences(Remember, I use postgres for it's functions, so there were many) sqlite uses a different parameter style(I e", "context": "", "use_case": "primary database", "switched_from": "", "story": "apsw: Another Python SQLite Wrapper"}, {"id": 800208706, "item_id": 50013044, "url": "https://news.ycombinator.com/item?id=50013044", "by": "eddietejeda", "date": "2026-10-08", "stance": "recommend", "quote": "We use Postgres as the catalog store, and it does not get much simpler than that", "excerpt": "Thanks for the shoutout. For context, we previously built custom catalogs optimized for specific use cases. But they were hard to maintain, especially as requirements changed, and Apache Iceberg was too heavy for our specific low-latency work. Since Ducklake is only a spec, we implemented datafusion-ducklake, and it performs as well as any custom or specialized catalog we built. We use Postgres as the catalog store, ", "context": "", "use_case": "catalog store", "switched_from": "", "story": "DuckDB Ducklake"}, {"id": 799845686, "item_id": 49990355, "url": "https://news.ycombinator.com/item?id=49990355", "by": "jdboyd", "date": "2026-10-07", "stance": "neutral", "quote": "it stores to postgresql running in a different VPS.", "excerpt": "Here are a few things I do: Host static content behind nginx Run filestash as a partial GoogleDrive replacement (I use it for sharing files with other people, like deliverables), files place on an S3 compatible object store. Run vaultwarder for myself and some family members. Run a container registry service backed by an s3 compatible object store. Run a django web application I wrote for my own use. However, it stor", "context": "runs a $5 VPS", "use_case": "database for Django app", "switched_from": "", "story": "Ask HN: What do you run on a $5 VPS that's worth keeping online 24/7?"}, {"id": 799835186, "item_id": 49989699, "url": "https://news.ycombinator.com/item?id=49989699", "by": "curioustinkerer", "date": "2026-10-07", "stance": "neutral", "quote": "Python, Django, FastAPI, PostgreSQL, Celery", "excerpt": "Location: Lucknow, India Remote: Yes Willing to relocate: No Technologies: Python, Django, FastAPI, PostgreSQL, Celery, LLM APIs (Gemini, Claude), agentic workflows, embeddings/clustering, GCP, Terraform R\u00e9sum\u00e9/CV: https://drive.google.com/file/d/1pulNpC8VJnV01pCzg0QRhgqOTazTWhk7/view Email: 5ifocyqgf@relay.firefox.com GitHub: https://github.com/abhiabhi94 Python backend engineer, 7+ years. Lately building LLM system", "context": "Python backend engineer, 7+ years", "use_case": "", "switched_from": "", "story": "Ask HN: Who wants to be hired? (October 2026)"}, {"id": 799781168, "item_id": 49986323, "url": "https://news.ycombinator.com/item?id=49986323", "by": "joaokwanza", "date": "2026-10-07", "stance": "neutral", "quote": "PostgreSQL, Kafka, Redis", "excerpt": "Location: Luanda, Angola (UTC+1) Remote: Yes Willing to relocate: Yes, with visa sponsorship: Portugal/EU, Canada, UK, Australia; open to a retention agreement on relocation costs Technologies: TypeScript/Node.js, Go, PostgreSQL, Kafka, Redis, AWS (Lambda, API Gateway, DynamoDB, S3, CloudFormation), Next.js/React, LLM agents, MCP R\u00e9sum\u00e9/CV: https://joaokwanza.com/cv.pdf Email: kwanzajoao04@gmail.com Senior backend & ", "context": "senior backend engineer", "use_case": "", "switched_from": "", "story": "Ask HN: Who wants to be hired? (October 2026)"}, {"id": 798820850, "item_id": 49926303, "url": "https://news.ycombinator.com/item?id=49926303", "by": "abumsoo", "date": "2026-10-01", "stance": "neutral", "quote": "PostgreSQL, Linux/UNIX", "excerpt": "Location: Southern California, USA Remote: Open to in-office, hybrid, or remote Willing to relocate: Yes, preferably within the USA Technologies: TypeScript, JavaScript, React, Python, C++, PostgreSQL, Linux/UNIX, Claude Code, GitHub Copilot R\u00e9sum\u00e9/CV: https://github.com/abumsoo/abumsoo/blob/main/BumSooKim_Resume.pdf GitHub: https://github.com/abumsoo LinkedIn: https://www.linkedin.com/in/bumskim/ Email: bum.s.kim42@", "context": "full stack engineer", "use_case": "", "switched_from": "", "story": "Ask HN: Who wants to be hired? (October 2026)"}, {"id": 798797826, "item_id": 49924864, "url": "https://news.ycombinator.com/item?id=49924864", "by": "36f", "date": "2026-10-01", "stance": "recommend", "quote": "My stack of choice would be FastAPI + Svelte + PostgreSQL", "excerpt": "I'm currently building and maintaining 36flats.de (https://codeberg.org/MagnoliaElectricCo/flathunter) and am looking for a new local position as a back end or full stack engineer, data engineer or similar. I worked in health tech in the past, and this project sparked my interest in working with geospatial data and building data pipelines. I'm happy to hear about your leads in either of those fields, or anything else", "context": "back end / full stack engineer job seeker", "use_case": "application database", "switched_from": "", "story": "Ask HN: Who wants to be hired? (October 2026)"}, {"id": 798761200, "item_id": 49922575, "url": "https://news.ycombinator.com/item?id=49922575", "by": "stakent", "date": "2026-10-01", "stance": "neutral", "quote": "Technologies: Python, PostgreSQL, FastAPI", "excerpt": "Location: Rzesz\u00f3w, Poland Remote: Yes \u2014 remote only (~EU hours or async) Willing to relocate: No Technologies: Python, PostgreSQL, FastAPI; LLMs & embeddings, semantic search, self-hosted open-weights models (on-prem, offline); deterministic data/ML pipelines; PDF/document extraction, OCR, IoT, time-series, logs \u2192 decision-useful information R\u00e9sum\u00e9/CV: https://walat.eu/cv/ | https://linkedin.com/in/dariusz-walat Emai", "context": "senior systems engineer seeking work", "use_case": "", "switched_from": "", "story": "Ask HN: Who wants to be hired? (October 2026)"}, {"id": 798344960, "item_id": 49896560, "url": "https://news.ycombinator.com/item?id=49896560", "by": "beepbooptheory", "date": "2026-09-29", "stance": "neutral", "quote": "It's the same reason why we use Postgres instead of hire database experts", "excerpt": "I guess this makes sense. I am no business guy, but if my product/company was focused on some sort of classification problem, my naive intuition would be to focus on hiring guys that can do it, rather than try to make the problem easier for them. But perhaps at the end of the day this is still cheaper? It's the same reason why we use Postgres instead of hire database experts to build something special?", "context": "", "use_case": "database", "switched_from": "", "story": "Jeff \u2013 Jev-compatible 0.8B decision models, trained at home, ~30 ms"}, {"id": 798107633, "item_id": 49881727, "url": "https://news.ycombinator.com/item?id=49881727", "by": "Imustaskforhelp", "date": "2026-09-28", "stance": "recommend", "quote": "postgresql is almost always good enough in my opinion", "excerpt": "Curious to know what does actually scale according to your opinion (if not postgres) and what is the scale that we are talking about when mentioning some of the largest databases ever built (I hope you can talk more about it!) There seems to be many many options at attempting/trying to scale postgresql, what are your opinions of them? Also It is my sort of opinion that you really have a good problem if postgresql isn", "context": "", "use_case": "general database", "switched_from": "", "story": "MongoDB CEO resigns to join Meta"}, {"id": 797006864, "item_id": 49812929, "url": "https://news.ycombinator.com/item?id=49812929", "by": "HerrlichDigital", "date": "2026-09-23", "stance": "recommend", "quote": "moved from a managed PostreSQL from fly.io to a self hosted version on a fly.io machine and it saved me around 30$ a month", "excerpt": "Let's see if this affects my setup. But maybe there are more tweaks i can do to cut costs if it rises to much. In the past i moved from a managed PostreSQL from fly.io to a self hosted version on a fly.io machine and it saved me around 30$ a month.", "context": "", "use_case": "self-hosted database on Fly.io", "switched_from": "Fly.io managed Postgres", "story": "Fly.io 2026 Pricing Update"}, {"id": 796940449, "item_id": 49808778, "url": "https://news.ycombinator.com/item?id=49808778", "by": "kstrauser", "date": "2026-09-22", "stance": "neutral", "quote": "others could run fast reports on our web app with a postgres backend", "excerpt": "Hey, I got to mention this recently! One of my bizarre claims to fame was writing this little tool[0] a few employers back to convert Visual FoxPro database files to PostgreSQL as part of a migration. For a while we had to run it as a cron job so that people could to data entry in an old VFP app but others could run fast reports on our web app with a postgres backend. It wasn't pretty, but it worked great and helped ", "context": "", "use_case": "reporting backend", "switched_from": "Visual FoxPro", "story": "Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived"}, {"id": 796688416, "item_id": 49793026, "url": "https://news.ycombinator.com/item?id=49793026", "by": "HerrlichDigital", "date": "2026-09-21", "stance": "neutral", "quote": "saved me $30 a month", "excerpt": "Is it really that easy to migrate to another DB Engine? I moved from managed PostgreSQL from fly.io to self-hosted PostgreSQL on a fly.io instance for my umami analytics, and it saved me $30 a month. But i haven't switched the Engine from MySQL to PostgreSQL.", "context": "", "use_case": "self-hosted database for analytics", "switched_from": "managed PostgreSQL", "story": "From MySQL to PostgreSQL: a much lighter server"}, {"id": 795840529, "item_id": 49740033, "url": "https://news.ycombinator.com/item?id=49740033", "by": "osigurdson", "date": "2026-09-17", "stance": "neutral", "quote": "I used .NET for many years with Postgres on a huge project.", "excerpt": "I used .NET for many years with Postgres on a huge project. Honestly, I don't know what you mean. Can you break down \"Everything\" a little. What is it that expects MSSQL? Who are the thought leaders pushing it? I'd say Microsoft's revenue related push with .NET these days is to try to subtly nudge you into Azure (where MSSQL is rare and Windows is virtually non-existent). But, I also think they know they will kill .N", "context": "", "use_case": "database for .NET project", "switched_from": "", "story": "Performance Improvements in .NET 11"}, {"id": 795748513, "item_id": 49734282, "url": "https://news.ycombinator.com/item?id=49734282", "by": "huahaiy", "date": "2026-09-16", "stance": "compare", "quote": "It is not hard to be more than 3x better than Postgres [1].", "excerpt": "81%is nothing. It is not hard to be more than 3x better than Postgres [1]. And you don\u2019t need a model to do that, let alone a 4B model. How much additional compute is needed to just run that model? [1] https://github.com/datalevin/datalevin/tree/master/benchmarks/JOB-bench", "context": "", "use_case": "query planning baseline", "switched_from": "", "story": "Training a 4B model to produce 81% faster query plans than Postgres"}, {"id": 794672737, "item_id": 49667046, "url": "https://news.ycombinator.com/item?id=49667046", "by": "jzelinskie", "date": "2026-09-11", "stance": "neutral", "quote": "we abused Postgres a lot while serving enterprise customers", "excerpt": "I love reading posts like this because it shows that authorization isn't as niche as it once was. I also empathize with avoiding dependencies when you ship enterprise software for running on-prem; we abused Postgres a lot while serving enterprise customers for Quay before we founded AuthZed/SpiceDB. As an engineer it's your job to decide when is the right time to use a dedicated system or continue to invest in your o", "context": "", "use_case": "on-prem enterprise software storage", "switched_from": "", "story": "How we rebuilt complex permissions without migrating to Zanzibar"}, {"id": 793815826, "item_id": 49613489, "url": "https://news.ycombinator.com/item?id=49613489", "by": "supz_k", "date": "2026-09-08", "stance": "neutral", "quote": "we use Postgres for both data storage and queue backend", "excerpt": "Hello HN, This is Supun from HYVOR. We've released 2.0 of our blogging platform, Hyvor Blogs. It's now open-source under AGPLv3 and easily self-hostable. Our framework is Symfony and we use Postgres for both data storage and queue backend. It's simple and also have powerful features like real-time collaborative editing, suggestion mode, AI features, etc. Self-hosting depends on OIDC SSO. With one instance self-hosted", "context": "works at HYVOR", "use_case": "data storage and queue", "switched_from": "", "story": "Hyvor Blogs, blogging platform, is now open-source and self-hostable"}, {"id": 793683008, "item_id": 49605188, "url": "https://news.ycombinator.com/item?id=49605188", "by": "frankheikens", "date": "2026-09-08", "stance": "neutral", "quote": "I\u2019ve been working with PostgreSQL for 20+ years", "excerpt": "Fair criticism on the writing. I used an LLM to help edit the post, and apparently didn\u2019t remove enough of its fingerprints. The software is a different matter. I\u2019ve been working with PostgreSQL for 20+ years, and I\u2019m happy to discuss or defend any of the technical decisions behind it here. Just ask!", "context": "20+ years PostgreSQL experience", "use_case": "database", "switched_from": "", "story": "We put an LLM in a PostgreSQL analyzer, then stopped letting it decide truth"}, {"id": 793631136, "item_id": 49601946, "url": "https://news.ycombinator.com/item?id=49601946", "by": "sysashi", "date": "2026-09-07", "stance": "recommend", "quote": "Annual postgres upgrades are always exciting (features) and terrifying (ops)", "excerpt": "`on conflict do select` and eager aggregation are the most notable for me, I use upserts and joins like that all the time. Annual postgres upgrades are always exciting (features) and terrifying (ops) :D (not that something can go wrong, I just feel anxiety hehe)", "context": "", "use_case": "upserts and joins", "switched_from": "", "story": "PostgreSQL 19 Interactive Tour"}, {"id": 793603153, "item_id": 49600197, "url": "https://news.ycombinator.com/item?id=49600197", "by": "ryanSrich", "date": "2026-09-07", "stance": "neutral", "quote": "Custom skills and their versions are stored in postgres", "excerpt": "Two ways I use skills 1. Personally - these are for apps I use like Codex. This one is pretty simple 2. For our product (which is mostly an internal tool, with minimial customer facing UI) - we have a skills factory that lets our employees create reusable instructions for our internal agent (fully custom built harness with routing). User describes the task and writes the instructions (can attach reference files, etc.", "context": "", "use_case": "storing skills and versions", "switched_from": "", "story": "Ask HN: How do you manage skills files?"}, {"id": 793430405, "item_id": 49589400, "url": "https://news.ycombinator.com/item?id=49589400", "by": "gourmetspam", "date": "2026-09-06", "stance": "neutral", "quote": "Stack is just Next.js / React + PostgreSQL hosted on Vercel + Supabase with GH Actions.", "excerpt": "I built Parsefin because I use tools like Dataroma and WhaleWisdom to follow what well-known investors are doing, but I was frustrated by the limited number of pre-selected investors available and terrible websites. Going to the SEC's website directly is also inefficient since you have to search for funds one-by-one, and you don't see the time series data. What Parsefin does: Parsefin parses SEC 13F/G/D portfolio dis", "context": "", "use_case": "database", "switched_from": "", "story": "Parsefin \u2013 A modern alternative to WhaleWisdom for 13F tracking"}, {"id": 793094496, "item_id": 49568406, "url": "https://news.ycombinator.com/item?id=49568406", "by": "philippta", "date": "2026-09-04", "stance": "compare", "quote": "I benchmarked Postgres in single- and muti-node setup against CockroachDB a while ago", "excerpt": "I benchmarked Postgres in single- and muti-node setup against CockroachDB a while ago and my findings match what this post is talking about. https://github.com/philippta/postgresql-cockroachdb-benchmark", "context": "", "use_case": "scaling benchmark", "switched_from": "", "story": "Ok, but does it scale?"}, {"id": 791904883, "item_id": 49494055, "url": "https://news.ycombinator.com/item?id=49494055", "by": "Kuyawa", "date": "2026-08-29", "stance": "recommend", "quote": "or postgresql if something more robust on your server", "excerpt": "I use a 1MB Rust shell with a webview (wry and winit). It works wonders Drop a SQLite db if you want a quick portable app, or postgresql if something more robust on your server. Tell your AI of choice [2] to create a TODO rust app [1] in html, css and js using wry and winit and you'll see what I mean, a thing of beauty [1] https://github.com/kuyawa/todo-rust [2] https://github.com/kuyawa/todo-rust/blob/main/prompt.tx", "context": "", "use_case": "server database", "switched_from": "", "story": "Ask HN: Any true alternatives to electron JavaScript?"}, {"id": 790239009, "item_id": 49389938, "url": "https://news.ycombinator.com/item?id=49389938", "by": "tofflos", "date": "2026-08-21", "stance": "neutral", "quote": "I've given up hope of it ever happening in PostgreSQL.", "excerpt": "> Previous blog posts have covered DuckDB\u2019s friendly SQL, including GROUP BY ALL and column selection using SELECT * EXCLUDE (...). I love the idea of friendly SQL! I often create views with the same shape and would love it if UNION and UNION ALL accepted a list. But it's not in the standard so I've given up hope of it ever happening in PostgreSQL. select * from view1 union all view2, view3, view4;", "context": "", "use_case": "", "switched_from": "", "story": "DuckDB V2 PEG-based SQL parser"}, {"id": 790081632, "item_id": 49380102, "url": "https://news.ycombinator.com/item?id=49380102", "by": "pojzon", "date": "2026-08-20", "stance": "recommend", "quote": "I love Postgres. Im using it for majority of my career in IT. It never failed me, even on very big scale.", "excerpt": "Its not a meme. Postgres does all of those things good enough to be always considered the first pick. I love Postgres. Im using it for majority of my career in IT. It never failed me, even on very big scale. Amazing piece of software.", "context": "IT career", "use_case": "general-purpose database", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 790011313, "item_id": 49375707, "url": "https://news.ycombinator.com/item?id=49375707", "by": "CodesInChaos", "date": "2026-08-20", "stance": "recommend", "quote": "For my next application I will use Postgres as primary database.", "excerpt": "My rule is \"use a single database for as many of you persistence needs as possible\". Often Postgres is a good choice for that database, but many other general purpose DBMSs will work just as well. In my previous company we used MongoDB, for almost everything, including text logs, request logs, job-queues and small template files. We added S3 since storing terabytes of files in a database is expensive. Now, I wouldn't", "context": "", "use_case": "primary database", "switched_from": "MongoDB", "story": "PostgreSQL for Everything"}, {"id": 789932624, "item_id": 49370789, "url": "https://news.ycombinator.com/item?id=49370789", "by": "frollogaston", "date": "2026-08-19", "stance": "neutral", "quote": "I use Postgres for a lot of things where textbooks say not to, but not caching.", "excerpt": "I use Postgres for a lot of things where textbooks say not to, but not caching. I'm not going to do it with triggers. Maybe if it supported TTL properly, even then, probably don't want to think about whether caching will bog down the rest of the DB.", "context": "", "use_case": "general data storage", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789916096, "item_id": 49369756, "url": "https://news.ycombinator.com/item?id=49369756", "by": "robomartin", "date": "2026-08-19", "stance": "recommend", "quote": "It worked very well. PostgreSQL maintained machine state, path planning, sensor readings, faults, operator input, etc.", "excerpt": "Years ago I used PostgreSQL under Django to drive an industrial test and inspection robotic cell (which I also designed and built) at a major technology company. It worked very well. PostgreSQL maintained machine state, path planning, sensor readings, faults, operator input, etc. I wanted to see how far I could push that toolset. It worked surprisingly well. Django's capabilities meant such things as multi-user login", "context": "designed and built industrial test robotic cell", "use_case": "robotic cell state and data", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789906465, "item_id": 49369154, "url": "https://news.ycombinator.com/item?id=49369154", "by": "throwitaway222", "date": "2026-08-19", "stance": "recommend", "quote": "just worked great for us on Postgres", "excerpt": "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", "context": "", "use_case": "job queue", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789836752, "item_id": 49364797, "url": "https://news.ycombinator.com/item?id=49364797", "by": "rgbrgb", "date": "2026-08-19", "stance": "recommend", "quote": "i'm still a postgres maximalist (worker queues still in pg [1])", "excerpt": "i love postgresql but once we added ai-generated dashboard to our homegrown analytics tool [0] some of the crazy (amazing) dashboards that the ops team was building began accumulating horrendously slow db queries. I considered dynamically adding indexes or alerting around postgres slow queries but also quickly prototyped mirroring the postgres data in clickhouse. At first could not believe how fast clickhouse was on ", "context": "", "use_case": "primary database and worker queues", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789810113, "item_id": 49363132, "url": "https://news.ycombinator.com/item?id=49363132", "by": "JaggerFoo", "date": "2026-08-19", "stance": "neutral", "quote": "I've used Postgres, Sqlite, Duckdb", "excerpt": "Use case matters. I use a SQL databases as needed. I've used Postgres, Sqlite, Duckdb, Json files with AWS Athena, Oracle enterprise for ERP systems (a multitude of schemas and objects with interoperability), and others. I'm currently, deploying Duckdb with AWS S3 Tables (Iceberg) to see how it fits for a use case I have. IT is great and always changing. Keep trying new things. Cheers", "context": "", "use_case": "", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789807249, "item_id": 49362953, "url": "https://news.ycombinator.com/item?id=49362953", "by": "lvncelot", "date": "2026-08-19", "stance": "recommend", "quote": "Postgres for all your GPU-based machine learning training and inference needs", "excerpt": "One addition: Postgres for all your GPU-based machine learning training and inference needs: https://github.com/postgresml/postgresml", "context": "", "use_case": "", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789795152, "item_id": 49362197, "url": "https://news.ycombinator.com/item?id=49362197", "by": "molf", "date": "2026-08-19", "stance": "recommend", "quote": "In most of the applications we build or maintain we use PostgreSQL + cloud storage. That's it. And it works very well", "excerpt": "I don't think the point is that PostgreSQL is great for everything. But you may get by with a single piece of infrastructure instead of 7. In most of the applications we build or maintain we use PostgreSQL + cloud storage. That's it. And it works very well, also for: storing JSON, full text search, as a queue, as a vector database. Other software may be better at providing those features, but I'm extremely happy we o", "context": "builds and maintains applications", "use_case": "JSON, full text search, queue, vector DB", "switched_from": "", "story": "PostgreSQL for Everything"}, {"id": 789728640, "item_id": 49358040, "url": "https://news.ycombinator.com/item?id=49358040", "by": "aurareturn", "date": "2026-08-19", "stance": "recommend", "quote": "It was surprisingly easy with a single large Postgres DB, a lot of caching, optimized tables and queries.", "excerpt": "HTTP traffic is different from run this CPU intensive pipeline service for 10 minutes and now increase the volume by 100x in a few months. I used to manage a popular app/website that had tens of billions of real user page views per month. It wasn't easy but it also wasn't hard. It was surprisingly easy with a single large Postgres DB, a lot of caching, optimized tables and queries.", "context": "managed a popular app/website with tens of billions of page views per month", "use_case": "high-traffic website backend", "switched_from": "", "story": "Incident with Github.com"}, {"id": 786025985, "item_id": 49126624, "url": "https://news.ycombinator.com/item?id=49126624", "by": "Imustaskforhelp", "date": "2026-07-31", "stance": "recommend", "quote": "both sqlite and postgres are awesome", "excerpt": "Yup its a really decent advice overall but I feel like there were some few use-cases I think where postgres made more sense but I found the initial setup to be slightly more complex than sqlite and oh I love both sqlite and postgres and was just thinking of merging somewhat all the things that I like about them haha but I get what you mean, both sqlite and postgres are awesome :)", "context": "", "use_case": "", "switched_from": "", "story": "Self-contained highly-portable Python distributions"}, {"id": 785851665, "item_id": 49115729, "url": "https://news.ycombinator.com/item?id=49115729", "by": "atombender", "date": "2026-07-30", "stance": "warn", "quote": "dead tuples start to accumulate due to Postgres' way of doing MVCC.", "excerpt": "A performance pitfall that isn't addressed in the DBOS article at all is the bloat problem: If you update or delete rows that you consume, dead tuples start to accumulate due to Postgres' way of doing MVCC. This is a serious problem because it affects the planner's ability to make good choices. Dead tuples are still indexed and the need to skip them isn't accounted for by the query planner, so a table with lots of de", "context": "", "use_case": "queue", "switched_from": "", "story": "Postgres Queues Actually Scale"}, {"id": 783256688, "item_id": 48953543, "url": "https://news.ycombinator.com/item?id=48953543", "by": "abrookewood", "date": "2026-07-17", "stance": "recommend", "quote": "Honestly, I love PostgreSQL, but now I have another server or service to run.", "excerpt": "Honestly, I love PostgreSQL, but now I have another server or service to run. SQLite is just a file and often, that is enough.", "context": "", "use_case": "", "switched_from": "", "story": "Learning a few things about running SQLite"}, {"id": 783240704, "item_id": 48952544, "url": "https://news.ycombinator.com/item?id=48952544", "by": "gnulinux", "date": "2026-07-17", "stance": "recommend", "quote": "I love postgres as much as the next person", "excerpt": "> run on postgresql with no overhead at all Citation needed. I love postgres as much as the next person, but it does have more overhead than Sqlite which is in an in-process db linked through compiled C code, it doesn't run as a separate server. Very significant difference that when you use Sqlite db, there is typically no db process other than your application logic, unless you implement the server yourself. If you ", "context": "", "use_case": "", "switched_from": "", "story": "Lobste.rs is now running on SQLite"}, {"id": 780913088, "item_id": 48807068, "url": "https://news.ycombinator.com/item?id=48807068", "by": "wuliwong", "date": "2026-07-06", "stance": "recommend", "quote": "I love the flexibility and all-in-one abilities of Postgres for prototyping and making MVPs.", "excerpt": "For context, I am mainly talking about my personal projects, ideas I am trying out, MVPs/prototypes for potential new businesses, etc. I have started just using Postgres to back queues. It is simpler (although I have spun up new apps with Redis so many times it is only a small improvement) but more importantly it is cheaper. I really do try a lot of stuff out, so completely removing a infrastructure piece is a nice m", "context": "builds personal projects and MVPs", "use_case": "queues and prototypes", "switched_from": "Redis", "story": "You probably don't need another database"}, {"id": 778670064, "item_id": 48666879, "url": "https://news.ycombinator.com/item?id=48666879", "by": "mikeocool", "date": "2026-06-24", "stance": "recommend", "quote": "I love Postgres.", "excerpt": "I love Postgres. I buy using it for many many things. I really don\u2019t understand why everyone insists that you should use it as a work/message queue. There are lots of purpose-built bullet proof queuing systems that are simple to setup and administer (or just use SQS). Your queue is likely to have very different access patterns than the rest of your data, and sticking it in Postgres means you\u2019re probably going to end ", "context": "", "use_case": "database", "switched_from": "", "story": "PostgreSQL Is Enough"}, {"id": 773029296, "item_id": 48314331, "url": "https://news.ycombinator.com/item?id=48314331", "by": "buremba", "date": "2026-05-28", "stance": "recommend", "quote": "All you need is Postgres until you scale into TBs of data.", "excerpt": "All you need is Postgres until you scale into TBs of data. We use Postgresql as a durable workflow engine, vector search, time-series data, BM25 search, OLTP/OLAP engine, and a queue. It's basically the only dependency we have for https://lobu.ai The main benefit is centralizing all the data in one place so we don't need to worry about copying data in between multiple systems. Once something becomes the bottleneck, y", "context": "", "use_case": "workflows, vector search, queue, OLTP/OLAP", "switched_from": "", "story": "Just Use Postgres for Durable Workflows"}, {"id": 765131968, "item_id": 47820748, "url": "https://news.ycombinator.com/item?id=47820748", "by": "mind-blight", "date": "2026-04-18", "stance": "warn", "quote": "I love the idea of pg as a queue, but I'm a more skeptical of it after dealing with it in production", "excerpt": "The vacuum pressure is real. Using a system with the skip locked technique + polling caused massive DB perf issues as the queue depth grew. The query to see the current jobs in the queue ended up being the main performance bottleneck, which cause slower throughput, which caused a larger queue depth, which etc. Scaling the workers sometimes exacerbates the problem because you run into connection limits or polling hamm", "context": "", "use_case": "job queue", "switched_from": "", "story": "PgQue: Zero-Bloat Postgres Queue"}]}