[planxty]

This author is spot on.

Raise your hand if you've committed the PostgreSQL to memory for looking at the DDL for a table, or identifying slow queries. Too many database management operations require highly specialized knowledge about a given database's internals.

Folks are far too willing to spend huge money on expensive licenses for db analytics tools to tell them when queries are slow or suboptimal.

Love the idea of making the db responsible for migrations. Downside there could be that db lock-in becomes a concern, and it might add cognitive overhead connecting application code to the current schema. How do you know if app code is up to date with the db without a live connection to prod?

[bluefirebrand]

> Downside there could be that db lock-in becomes a concern

Lock-in is often mentioned as a downside to tech, but in my experience the budget never exists to change tech past a certain point anyways.

Honestly it always seems like an argument for better upfront planning, to me. Start out by assuming you're going to be locked-in to your choices forever, and make those choices with care.

[sokoloff]

Why would I want to have the examine DDL or slow query query committed to memory? I need to know that the concept exists and I can google the syntax in 90 seconds. I’m never within 90 seconds of disaster avertable with this knowledge.

[planxty]

Of course anyone can look anything up. The point I think the author is making is that the database is better positioned to tell us about potential performance issues. Would be wonderful if we could avoid reading through slow query logs, or paying big money for APM tools, if the db exposed more user friendly information about perf issues or other useful metadata.

The UX of 'damn I have to look that one weird query up again' to look up some metadata is not as good as it could be.

[hobs]

You dont, you just have so many times that it happens (me.)