{"slug": "amazon-rds", "name": "Amazon RDS", "category": "databases", "category_name": "Databases", "description": "", "recommenders": 6, "commenters": 25, "warners": 12, "score": -3.703, "rising": -1.96, "first": "2025-11-03", "latest": "2026-06-08", "why": "Use EC2, EBS, S3, Route53 plus EKS, RDS, ElastiCache.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 6, "neutral": 3, "compare": 4, "warn": 13}, "spark": [3, 1, 0, 1, 0, 0, 0, 1, 0, 0, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "Use EC2, EBS, S3, Route53 plus EKS, RDS, ElastiCache.", "kind": "", "icon": true, "domain": null, "github_repo": null, "official_url": "https://aws.amazon.com/rds/", "pricing": "", "aliases": ["Amazon RDS", "AWS RDS"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 775187973, "item_id": 48449248, "url": "https://news.ycombinator.com/item?id=48449248", "by": "paulddraper", "date": "2026-06-08", "stance": "recommend", "quote": "Use EC2, EBS, S3, Route53 plus EKS, RDS, ElastiCache.", "excerpt": "You should really stay away from any \"high level\" AWS product, as there is almost always something much better and more flexible. Use EC2, EBS, S3, Route53 plus EKS, RDS, ElastiCache. But anything else that isn't low-to-mid-level (looking at you Beanstalk), use something better. Clerk, WorkOS, etc.", "context": "", "use_case": "managed databases", "switched_from": "", "story": "Amazon Cognito now supports multi-Region replication"}, {"id": 753321410, "item_id": 47082588, "url": "https://news.ycombinator.com/item?id=47082588", "by": "0xbadcafebee", "date": "2026-02-19", "stance": "recommend", "quote": "RDS for production is great", "excerpt": "Using GCP gives me the same feeling as vibe-coded source code. Technically works but deeply unsettling. Unless GCP is somehow saving you boatloads of cash, AWS is much better. RDS is a very quick way to expand your bill, followed by EC2, followed by S3. RDS for production is great, but you should avoid the bizarre HN trope of \"Postgres for everything\" with RDS. It makes your database unnecessarily larger which expand", "context": "", "use_case": "production databases", "switched_from": "", "story": "Almost Every infrastructure decision I endorse or regret after 4 years"}, {"id": 741401841, "item_id": 46337615, "url": "https://news.ycombinator.com/item?id=46337615", "by": "scott_w", "date": "2025-12-20", "stance": "recommend", "quote": "we use RDS for our app DB", "excerpt": "> Every company out there is using the cloud and yet still employs infrastructure engineers to deal with its complexity. The \"cloud\" reducing staff costs is and was always a lie. This doesn\u2019t make sense as an argument. The reason the cloud is more complex is because that complexity is available. Under a certain size, a large number of cloud products simply can\u2019t be managed in-house (and certainly not altogether). Als", "context": "", "use_case": "Managed application database", "switched_from": "", "story": "Go ahead, self-host Postgres"}, {"id": 735048161, "item_id": 45940510, "url": "https://news.ycombinator.com/item?id=45940510", "by": "mooreds", "date": "2025-11-15", "stance": "recommend", "quote": "using some of the managed services, which are rock solid", "excerpt": "> For personal projects I end up avoiding AWS and instead prefer things like the Backblaze S3-compatible object storage, Vultr for VMs, and so on just to avoid the power user features that will only get in the way. The author wrote an article about this too: https://www.theregister.com/2025/11/04/aws_genz_misery_nope/ > With that, I am curious how people who do not have an enterprise-size team to manage their AWS inf", "context": "Former startup CTO", "use_case": "Managed databases", "switched_from": "", "story": "AWS deprecates two dozen services (most of which you've never heard of)"}, {"id": 735046642, "item_id": 45940415, "url": "https://news.ycombinator.com/item?id=45940415", "by": "tyre", "date": "2025-11-15", "stance": "recommend", "quote": "I've found that AWS does a pretty good job, like in the postgres compatible RDS case, of suggesting defaults", "excerpt": "They've gotten much better at streamlining setup and suggesting sane defaults over the years. I hear the GP that there soooo many knobs. I've found that AWS does a pretty good job, like in the postgres compatible RDS case, of suggesting defaults that make sense for most people. And when you run into issues / scaling problems, you can Claude your way to which settings to research. The only one that still drives me ins", "context": "", "use_case": "", "switched_from": "", "story": "AWS deprecates two dozen services (most of which you've never heard of)"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 767489920, "item_id": 47968120, "url": "https://news.ycombinator.com/item?id=47968120", "by": "subhobroto", "date": "2026-04-30", "stance": "warn", "quote": "I've heard the same thing in the past from people attempting to use RDS", "excerpt": "You've given us some idea of the volume of your data but there's no mention of what's ingesting it or how. > during these stress tests the hardware is nowhere close to over-encumbered, and there's consistent headroom on both memory, CPU and disk I/O This assertion is likely wrong - you're likely skipping over some metrics that has clues to what we need to know. Here are some questions to get the discussion moving. - ", "context": "", "use_case": "", "switched_from": "", "story": "Does Postgres Scale?"}, {"id": 766809107, "item_id": 47925569, "url": "https://news.ycombinator.com/item?id=47925569", "by": "matebajusz", "date": "2026-04-27", "stance": "warn", "quote": "RDS PostgreSQL \u201clegacy fee\u201d \u2014 ~\u20ac200* for March", "excerpt": "I've been hosting one of my side projects on AWS. The project actually did quite well for a while, generating a few thousand euros per month. Then COVID hit, regulations changed, and the problem it solved basically disappeared overnight. Revenue dropped to zero, the startup credits I received held out for quite some time, after that I kept the project running, paying out of pocket, thinking maybe it would recover. Th", "context": "", "use_case": "hosted PostgreSQL", "switched_from": "", "story": "Show HN: Remote Access for Home Assistant Without Nabu Casa"}, {"id": 765067892, "item_id": 47816743, "url": "https://news.ycombinator.com/item?id=47816743", "by": "faangguyindia", "date": "2026-04-18", "stance": "warn", "quote": "they cost soo much compared to running your own stuff", "excerpt": "database isn't hard to have HA with, it's actually very easy to do any of this. i already design with Auto Scale Group in mind, we run it in spot instance which tend to be much cheaper. Spot instances can be reclaimed anytime, so you need to keep this is kind. I also have data blobs which are memory maped files, which are swapped with no downtime by pulling manifest from GCS bucket each hour, and swapping out the mma", "context": "", "use_case": "", "switched_from": "", "story": "Migrating from DigitalOcean to Hetzner: From $1,432 to $233 With Zero Downtime"}, {"id": 756757651, "item_id": 47297353, "url": "https://news.ycombinator.com/item?id=47297353", "by": "kencho", "date": "2026-03-08", "stance": "warn", "quote": "we replaced pinecone and rds with neon under the hood", "excerpt": "pgvector is great if you're already on postgres and only need text search. funny enough, Neon Postgres actually featured us in a case study about this exact topic. we replaced pinecone and rds with neon under the hood: https://neon.com/blog/vecstore-replacing-pinecone-and-rds-with-neon the gap shows up when you need image search, face search, or content moderation on top of text search. that's where a dedicated api m", "context": "", "use_case": "", "switched_from": "", "story": "You Don't Need a Vector Database"}]}], "who": [{"by": "mooreds", "context": "Former startup CTO", "url": "https://news.ycombinator.com/item?id=45940510", "date": "2025-11-15"}, {"by": "jakewindle47", "context": "full-stack engineer, 10+ years", "url": "https://news.ycombinator.com/item?id=45803271", "date": "2025-11-03"}], "tags": [], "use_cases": ["managed databases", "hosted postgresql", "production databases", "managed database", "managed application database", "business app databases"], "compared": [{"slug": "postgresql", "name": "PostgreSQL", "co": 9, "switched_from": 0, "switched_to": 1}, {"slug": "amazon-s3", "name": "Amazon S3", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "terraform", "name": "Terraform", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "neon", "name": "Neon", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "sqlite", "name": "SQLite", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "docker", "name": "Docker", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=46379765", "title": "Postgres extension complements pgvector for performance and scale", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=47966625", "title": "Does Postgres Scale?", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=47899669", "title": "Pgrx: Build Postgres Extensions with Rust", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=46336947", "title": "Go ahead, self-host Postgres", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=45939678", "title": "AWS deprecates two dozen services (most of which you've never heard of)", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=48446521", "title": "Amazon Cognito now supports multi-Region replication", "mentions": 1}], "sentiment_by_month": {"2025-11": {"neutral": 2, "warn": 2, "recommend": 3, "compare": 1}, "2025-12": {"compare": 1, "recommend": 1, "warn": 4}, "2026-01": {"warn": 1}, "2026-02": {"neutral": 1, "warn": 1, "recommend": 1}, "2026-03": {"warn": 1}, "2026-04": {"warn": 4, "compare": 1}, "2026-05": {"compare": 1}, "2026-06": {"recommend": 1}, "2026-07": {}, "2026-08": {}, "2026-09": {}, "2026-10": {}}, "quotes": [{"id": 775187973, "item_id": 48449248, "url": "https://news.ycombinator.com/item?id=48449248", "by": "paulddraper", "date": "2026-06-08", "stance": "recommend", "quote": "Use EC2, EBS, S3, Route53 plus EKS, RDS, ElastiCache.", "excerpt": "You should really stay away from any \"high level\" AWS product, as there is almost always something much better and more flexible. Use EC2, EBS, S3, Route53 plus EKS, RDS, ElastiCache. But anything else that isn't low-to-mid-level (looking at you Beanstalk), use something better. Clerk, WorkOS, etc.", "context": "", "use_case": "managed databases", "switched_from": "", "story": "Amazon Cognito now supports multi-Region replication"}, {"id": 767940914, "item_id": 47996307, "url": "https://news.ycombinator.com/item?id=47996307", "by": "subhobroto", "date": "2026-05-03", "stance": "compare", "quote": "In the days of AWS RDS", "excerpt": "> On the whole, in fact, it looks like all of the combined advice clear this hurdle up so much that we can no longer say we observe Postgres having an actual problem dealing with our current volumes and intensity of ingestion. I am extremely happy for you! This is fantastic news. I would really appreciate a followup post on DB SE and/or PostgreSQL ML because I assure you, there are others in your position. A deeply n", "context": "", "use_case": "", "switched_from": "", "story": "Does Postgres Scale?"}, {"id": 767489920, "item_id": 47968120, "url": "https://news.ycombinator.com/item?id=47968120", "by": "subhobroto", "date": "2026-04-30", "stance": "warn", "quote": "I've heard the same thing in the past from people attempting to use RDS", "excerpt": "You've given us some idea of the volume of your data but there's no mention of what's ingesting it or how. > during these stress tests the hardware is nowhere close to over-encumbered, and there's consistent headroom on both memory, CPU and disk I/O This assertion is likely wrong - you're likely skipping over some metrics that has clues to what we need to know. Here are some questions to get the discussion moving. - ", "context": "", "use_case": "", "switched_from": "", "story": "Does Postgres Scale?"}, {"id": 766950449, "item_id": 47934403, "url": "https://news.ycombinator.com/item?id=47934403", "by": "setr", "date": "2026-04-28", "stance": "compare", "quote": "RDS also has a curated set of extensions?", "excerpt": "RDS also has a curated set of extensions? https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html Which includes literally all 4 extensions you\u2019ve mentioned. Every managed service does this, specifically because they need to blacklist extensions that touch on the managed parts of it \u2014 eg filesystem", "context": "", "use_case": "", "switched_from": "", "story": "Pgrx: Build Postgres Extensions with Rust"}, {"id": 766901138, "item_id": 47931321, "url": "https://news.ycombinator.com/item?id=47931321", "by": "K0nserv", "date": "2026-04-28", "stance": "warn", "quote": "", "excerpt": "I built https://github.com/k0nserv/plid with Pgrx and had a great time. I did have to scale back some of the magic (dropping derive PostgresType etc), but even so the support pgrx provides is excellent. I also talked to the maintainers a bit in discord and they were super helpful. The one downside of custom extensions is that you aren\u2019t, AFAIK, able to use them with many hosted Postgres installs, notably AWS RDS.", "context": "", "use_case": "", "switched_from": "", "story": "Pgrx: Build Postgres Extensions with Rust"}, {"id": 766809107, "item_id": 47925569, "url": "https://news.ycombinator.com/item?id=47925569", "by": "matebajusz", "date": "2026-04-27", "stance": "warn", "quote": "RDS PostgreSQL \u201clegacy fee\u201d \u2014 ~\u20ac200* for March", "excerpt": "I've been hosting one of my side projects on AWS. The project actually did quite well for a while, generating a few thousand euros per month. Then COVID hit, regulations changed, and the problem it solved basically disappeared overnight. Revenue dropped to zero, the startup credits I received held out for quite some time, after that I kept the project running, paying out of pocket, thinking maybe it would recover. Th", "context": "", "use_case": "hosted PostgreSQL", "switched_from": "", "story": "Show HN: Remote Access for Home Assistant Without Nabu Casa"}, {"id": 765067892, "item_id": 47816743, "url": "https://news.ycombinator.com/item?id=47816743", "by": "faangguyindia", "date": "2026-04-18", "stance": "warn", "quote": "they cost soo much compared to running your own stuff", "excerpt": "database isn't hard to have HA with, it's actually very easy to do any of this. i already design with Auto Scale Group in mind, we run it in spot instance which tend to be much cheaper. Spot instances can be reclaimed anytime, so you need to keep this is kind. I also have data blobs which are memory maped files, which are swapped with no downtime by pulling manifest from GCS bucket each hour, and swapping out the mma", "context": "", "use_case": "", "switched_from": "", "story": "Migrating from DigitalOcean to Hetzner: From $1,432 to $233 With Zero Downtime"}, {"id": 756757651, "item_id": 47297353, "url": "https://news.ycombinator.com/item?id=47297353", "by": "kencho", "date": "2026-03-08", "stance": "warn", "quote": "we replaced pinecone and rds with neon under the hood", "excerpt": "pgvector is great if you're already on postgres and only need text search. funny enough, Neon Postgres actually featured us in a case study about this exact topic. we replaced pinecone and rds with neon under the hood: https://neon.com/blog/vecstore-replacing-pinecone-and-rds-with-neon the gap shows up when you need image search, face search, or content moderation on top of text search. that's where a dedicated api m", "context": "", "use_case": "", "switched_from": "", "story": "You Don't Need a Vector Database"}, {"id": 753321410, "item_id": 47082588, "url": "https://news.ycombinator.com/item?id=47082588", "by": "0xbadcafebee", "date": "2026-02-19", "stance": "recommend", "quote": "RDS for production is great", "excerpt": "Using GCP gives me the same feeling as vibe-coded source code. Technically works but deeply unsettling. Unless GCP is somehow saving you boatloads of cash, AWS is much better. RDS is a very quick way to expand your bill, followed by EC2, followed by S3. RDS for production is great, but you should avoid the bizarre HN trope of \"Postgres for everything\" with RDS. It makes your database unnecessarily larger which expand", "context": "", "use_case": "production databases", "switched_from": "", "story": "Almost Every infrastructure decision I endorse or regret after 4 years"}, {"id": 750560096, "item_id": 46910006, "url": "https://news.ycombinator.com/item?id=46910006", "by": "darkwater", "date": "2026-02-05", "stance": "warn", "quote": "maxing out connections on RDS", "excerpt": "There is still a max capped on the instance size [1] (well, RAM available) although now that I'm checking it again I swear it was different last time I read it. Anyway I did totally had issues with big replicated monoliths with their own connection pool (i.e. old Rails) maxing out connections on RDS. [1] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html#RDS_Limits.MaxConnections", "context": "", "use_case": "", "switched_from": "", "story": "Postgres Postmaster does not scale"}, {"id": 750505363, "item_id": 46906585, "url": "https://news.ycombinator.com/item?id=46906585", "by": "kokanee", "date": "2026-02-05", "stance": "neutral", "quote": "I really just wish RDS supported the timescale extension", "excerpt": "I love postgres and it really is a supertool. But to get exactly what you need can require digging deep and really having control over the lowest levels. My experience after using timescale/tigerdata for the last couple years is that I really just wish RDS supported the timescale extension; TigerData's layers on top of that have caused as many problems as they've solved.", "context": "", "use_case": "", "switched_from": "", "story": "It's 2026, Just Use Postgres"}, {"id": 748470112, "item_id": 46779382, "url": "https://news.ycombinator.com/item?id=46779382", "by": "LunaSea", "date": "2026-01-27", "stance": "warn", "quote": "AWS RDS is about 10x more expensive than bare metal", "excerpt": "> Well for one thing, call me a sell-out or accuse me of lacking craftsmanship, but I like my databases managed. I had the same worries and then we moved to OVH and Hetzner and had no issues. AWS RDS is about 10x more expensive than bare metal with maybe 1/4th the disk performance. Regarding operations I simply setup a primary and read replica together with a PGBackRest continuous archiving and backup solution to a S", "context": "", "use_case": "managed database", "switched_from": "", "story": "France Aiming to Replace Zoom, Google Meet, Microsoft Teams, etc."}, {"id": 743001792, "item_id": 46437612, "url": "https://news.ycombinator.com/item?id=46437612", "by": "mrinterweb", "date": "2025-12-30", "stance": "warn", "quote": "(also not available on RDS)", "excerpt": "I'm considering hosting a separate pg db just to be able to access certain extensions. I am interested in this extension as well as https://wiki.postgresql.org/wiki/Incremental_View_Maintenance (also not available on RDS). Then use logical replication for specific data source tables (guess it would need to be DMS).", "context": "", "use_case": "", "switched_from": "", "story": "Postgres extension complements pgvector for performance and scale"}, {"id": 742991666, "item_id": 46436979, "url": "https://news.ycombinator.com/item?id=46436979", "by": "jascha_eng", "date": "2025-12-30", "stance": "warn", "quote": "moved from rds to tiger cloud", "excerpt": "We have a lot of happy customers that moved from rds to tiger cloud if you think pgvectorscale is interesting to you and you don't want to self host pg. But yes big cloud providers move slow in adopting extensions.", "context": "", "use_case": "", "switched_from": "", "story": "Postgres extension complements pgvector for performance and scale"}, {"id": 742973968, "item_id": 46435873, "url": "https://news.ycombinator.com/item?id=46435873", "by": "tacoooooooo", "date": "2025-12-30", "stance": "warn", "quote": "", "excerpt": "correct afaik :( https://github.com/timescale/pgvectorscale/issues/113", "context": "", "use_case": "", "switched_from": "", "story": "Postgres extension complements pgvector for performance and scale"}, {"id": 741406626, "item_id": 46337914, "url": "https://news.ycombinator.com/item?id=46337914", "by": "jurschreuder", "date": "2025-12-20", "stance": "warn", "quote": "I moved from AWS RDS to ScaleWay RDS, had the same effect on cost", "excerpt": "I moved from AWS RDS to ScaleWay RDS, had the same effect on cost", "context": "", "use_case": "", "switched_from": "", "story": "Go ahead, self-host Postgres"}, {"id": 741401841, "item_id": 46337615, "url": "https://news.ycombinator.com/item?id=46337615", "by": "scott_w", "date": "2025-12-20", "stance": "recommend", "quote": "we use RDS for our app DB", "excerpt": "> Every company out there is using the cloud and yet still employs infrastructure engineers to deal with its complexity. The \"cloud\" reducing staff costs is and was always a lie. This doesn\u2019t make sense as an argument. The reason the cloud is more complex is because that complexity is available. Under a certain size, a large number of cloud products simply can\u2019t be managed in-house (and certainly not altogether). Als", "context": "", "use_case": "Managed application database", "switched_from": "", "story": "Go ahead, self-host Postgres"}, {"id": 738033377, "item_id": 46127086, "url": "https://news.ycombinator.com/item?id=46127086", "by": "andrewvc", "date": "2025-12-02", "stance": "compare", "quote": "What\u2019s more common is the use case managed databases like RDS etc solves for.", "excerpt": "The HN SQLite worship posts have gotten out of hand. What\u2019s next a post on how appending to files is faster than Kafka? It\u2019s great that some people have workloads that this is a fit for. What\u2019s more common is the use case managed databases like RDS etc solves for. You have some quantity of data you want to always be there, be available over a network for whatever app(s) need it and want backups, upgrades, access cont", "context": "", "use_case": "business app databases", "switched_from": "", "story": "100k TPS over a billion rows: the unreasonable effectiveness of SQLite"}, {"id": 735922945, "item_id": 45995184, "url": "https://news.ycombinator.com/item?id=45995184", "by": "sgarland", "date": "2025-11-20", "stance": "compare", "quote": "I have never found it to beat RDS", "excerpt": "Except it isn\u2019t nearly as fast as it claims [0]. And in real-world tests, I have never found it to beat RDS. You can get an insane amount of performance out of a well-tuned MySQL or Postgres instance, especially if you\u2019ve designed your schema to exploit your RDBMS\u2019 strengths (e.g. taking advantage of InnoDB\u2019s clustering index to minimize page fetches for N:M relationships). And if you really need high performance, yo", "context": "", "use_case": "", "switched_from": "", "story": "A $1k AWS mistake"}, {"id": 735048161, "item_id": 45940510, "url": "https://news.ycombinator.com/item?id=45940510", "by": "mooreds", "date": "2025-11-15", "stance": "recommend", "quote": "using some of the managed services, which are rock solid", "excerpt": "> For personal projects I end up avoiding AWS and instead prefer things like the Backblaze S3-compatible object storage, Vultr for VMs, and so on just to avoid the power user features that will only get in the way. The author wrote an article about this too: https://www.theregister.com/2025/11/04/aws_genz_misery_nope/ > With that, I am curious how people who do not have an enterprise-size team to manage their AWS inf", "context": "Former startup CTO", "use_case": "Managed databases", "switched_from": "", "story": "AWS deprecates two dozen services (most of which you've never heard of)"}, {"id": 735046642, "item_id": 45940415, "url": "https://news.ycombinator.com/item?id=45940415", "by": "tyre", "date": "2025-11-15", "stance": "recommend", "quote": "I've found that AWS does a pretty good job, like in the postgres compatible RDS case, of suggesting defaults", "excerpt": "They've gotten much better at streamlining setup and suggesting sane defaults over the years. I hear the GP that there soooo many knobs. I've found that AWS does a pretty good job, like in the postgres compatible RDS case, of suggesting defaults that make sense for most people. And when you run into issues / scaling problems, you can Claude your way to which settings to research. The only one that still drives me ins", "context": "", "use_case": "", "switched_from": "", "story": "AWS deprecates two dozen services (most of which you've never heard of)"}, {"id": 734901408, "item_id": 45931338, "url": "https://news.ycombinator.com/item?id=45931338", "by": "jaggederest", "date": "2025-11-14", "stance": "warn", "quote": "I don't care for the way RDS limits your options on extensions and configuration", "excerpt": "I've had better results with managing my own clusters on metal instances. You get much better performance with e.g. NVMe drives in a 0+1 raid (~million iops in a pure raid 0 with 7 drives) and I am comfortable running my own instances and clusters. I don't care for the way RDS limits your options on extensions and configuration, and I haven't had a good time with the high availability failovers internally, I'd rather", "context": "", "use_case": "", "switched_from": "", "story": "A race condition in Aurora RDS"}, {"id": 733208128, "item_id": 45825508, "url": "https://news.ycombinator.com/item?id=45825508", "by": "Zaheer", "date": "2025-11-05", "stance": "recommend", "quote": "Handy feature for accomplishing similar goal", "excerpt": "I recently learned that on RDS you can import data from S3. Handy feature for accomplishing similar goal: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.S3Import.html", "context": "", "use_case": "Importing data from S3", "switched_from": "", "story": "Moving tables across PostgreSQL instances"}, {"id": 733091282, "item_id": 45818205, "url": "https://news.ycombinator.com/item?id=45818205", "by": "koito17", "date": "2025-11-04", "stance": "warn", "quote": "That is already triple the cost of the NAS in my bedroom.", "excerpt": "12 TB fits entirely into the RAM of a 2U server (cf. Dell PowerEdge R840). However, I think there's an implicit point in TFA; namely, that your personal and side projects are not scaling to a 12 TB database. With that said, I do manage approximately 14 TB of storage in a RAIDZ2 at my home, for \"Linux ISOs\". The I/O performance is \"good enough\" for streaming video and BitTorrent seeding. However, I am not sure what yo", "context": "", "use_case": "managed database hosting", "switched_from": "", "story": "I took all my projects off the cloud, saving thousands of dollars"}, {"id": 732854422, "item_id": 45803401, "url": "https://news.ycombinator.com/item?id=45803401", "by": "LaraHealth", "date": "2025-11-03", "stance": "neutral", "quote": "Skills: AI agents, Python, Node.js, AWS Lambda, API Gateway, DynamoDB, S3, CloudFormation, Terraform, RDS, Pytest, Docker, Kubernetes", "excerpt": "Lara Health | https://lara.health | Senior Back-end Engineer| USA | REMOTE | Full-time Lara Health is on a mission to transform how healthcare is delivered for chronic care management. We enhance patient care, improve operational efficiency, and create new, diverse revenue streams for healthcare organizations. Skills: AI agents, Python, Node.js, AWS Lambda, API Gateway, DynamoDB, S3, CloudFormation, Terraform, RDS, P", "context": "", "use_case": "managed relational databases", "switched_from": "", "story": "Ask HN: Who is hiring? (November 2025)"}, {"id": 732852347, "item_id": 45803271, "url": "https://news.ycombinator.com/item?id=45803271", "by": "jakewindle47", "date": "2025-11-03", "stance": "neutral", "quote": "AWS (ECS, Lambda, RDS, DynamoDB)", "excerpt": "Location: Durham, North Carolina Remote: Yes Willing to relocate: No Technologies: Python, Java, C++, Go, JavaScript/React, AI/ML (LLMs, RAG, Embeddings, Fine-tuning), AWS (ECS, Lambda, RDS, DynamoDB), Terraform, Docker, Spring Boot, Django, PostgreSQL, Redis, spaCy, scikit-learn R\u00e9sum\u00e9/CV: https://github.com/jaketothepast/resume/blob/main/resume.pdf Email: jacob.windle@hey.com I'm a full-stack engineer with 10+ year", "context": "full-stack engineer, 10+ years", "use_case": "", "switched_from": "", "story": "Ask HN: Who wants to be hired? (November 2025)"}]}