It's all about trade off.

Do you want to spend thousands of dollar upfront for that DB server with sweet sweet NVME SSDs, of which your application might not even use 1% before the app get scraped?

> Too many engineers don't understand how (...) VMs with chatty neighbors are compared to bare metal

sell a lie, blame the victim?

What happens when a new version is deployed?

>If my #1 requirement is lowest possible latency, I can't imagine picking anything else.

optane

What approach do you take for backups?

NAS/SAN still make sense when you need to share storage between multiple DBs for efficiency: most DBs are tiny compared to the size of an SSD.

Mostly agree, but then you have to take care of replication, failover, and backup. By using a replicated block storage, you can mostly externalize that problem.

When the host dies with local storage, the VM is dead. With EBS it's not, since it simply can be booted up on another host. EBS is also replicated accross multiple hosts.

Reliability. A general-purpose DBMS probably has multiple decades of battle-testing, your vibecoded DBMS doesn't.

For the same reason I want my car to have FSD instead of my FSD to know how to assemble a car to drive by itself.

Opportunity cost. If getting rid of Postgres is going to make you more money, go right ahead. More likely though, you have other problems to be dealing with that are more directly in line with your work.

There's a balance to be had between a highly specialised custom tool that does exactly what you need now, versus a generalist tool that does what you do today and more but is less optimised for your specific use-case today. That, and standing on the shoulders of giants, knowing why those fences are there, and so on.

try it and see :) check out that Goose language. you’ll quickly realize your agents are idiots and need reams of PDFs that YOU don’t know how to select and filter down to even have good ideas, and then will drift forever failing to “seam” the contracts between the storage, query planning, and compilation layers.

1. You don’t have those speed requirements, and if you do, you already know the answer to your question. 2. Data tends to be somewhat important to a lot of companies. A vibe-coded database increases your risk of losing that data. 3. Your database might have clients using different languages. Now, your vibe-coded drivers become another layer of potential problems. 4. People has been doing this since way before 2023 btw, most probably agree Postgres would be the sane choice.

Who is stopping you?

That’s a pretty common title format for talks or blog posts long before LLMs existed.

I'm starting to find complaints about AI generated content more annoying than the content being complained about.

That's a load-bearing statement.

Yes. My experience: "Oh interesting title". "Oh god... slop galore. Disappointment, sadness, dejection, a feeling of being dismissed and not taken seriously, alienation from the world", "OK close the link".

Happy to still be here among my fellow humans. Hackernews the last bastion it feels like.

Can we somehow filter out slop from the front page? That would be great :).

> that is not the only problem just because it's the one you deal with

Sure. But to be clear: I am not denying storage is a genuine problem for some people.

I am just saying in the majority of cases it's probably not "the storage". For most people "the storage" will be quite far down the list of likely causes of a "slow" database.

Throw all the Enterprise SSDs or other storage solutions you like at a shitty schema and it will still struggle under load (or sometimes just struggle full stop).

Sit down, think about the queries you are using, and think about how the tables are updated. Now take that and rethink your indexes. Use the right index type for the right situation, don’t just slap a basic index on a serial id field and call it a day. And while you’re at it, think about the ID fields you use, sometimes better options exist. UUIDv7 is now built in, use it.

Lots of things in PGSQL benefit from thinking about how your use case is manipulating the underlying B-tree, if you work in performance sensitive stuff the devil is really in the details. And having to rebuild indexes that have decayed over time is painful.

Column Tetris is one example: https://stackoverflow.com/questions/2966524/calculating-and-....

Optimizing column layout has been enough for me to leave OLAP workloads in Postgres a few times when I otherwise would've had to spin up something dedicated for them.

> Which postgres specific schema/query features do you use to significantly improve performance?

Erm. Isn't this kind of a schema specific question ?

I mean, sometimes I see schemas that are so goddam awful that the answer to your question would be "anything, literally anything".

Other times its the old story of failing to use or misconfiguring indexes.

And then, yes you end up in the realms of Postgres specific stuff. What you do there clearly depends on what you're looking at.

But the point is, I could probably count on one hand the number of times the problem has been "the storage" or "the database". Most of the time its "the developer". :D