Thanks for the response. It is indeed an opinionated article, but not so much:

- The whole point of this article is targeting the things you're mentioning. A DBA team owning and managing databases, data and reports shouldn't exist by default.

If you have that setup, then yes SP are the only contracts you can share to manage both teams. Regardless if there's any benefit...

But for most people where this rare/legacy setup does not exist. There's better ways even if you have complex reports and tons of data to manage. In the modern world, SDEs are owning every aspect of software. Tests, Infrastructure, Delivery, Data etc...

Members of your team or dedicated Data Engineers can take on those tasks and build proper pipelines and reports, DataHub, Looker and Snowflake are to consider here.

That's how reporting scale, having a DBA team does not scale well in contrast where work would be deduplicated, require huge collaboration and is very prone to failures.

- What I meant by function is more like a C# or Java function, query plan, caching and optimising queries are a good read but the idea mentioned is that you shouldn't need that at that stage.

There's a spectrum of how to balance the load between the database and the backend calling application. It is much faster and much more scalable to start with the latter. Databases are cheap, most of them supports sharding and partitioning. Performance isn't an argument here or is a very "niche" one.

You're right, everything has an it depends and context is key. Having SPs is a red flag in the modern world, it is the exception and not the norm. And my younger self or a young developer reading this article would love to see that. Either to move out jobs, or to know what to look for.

Shaping your career on your first job is a hit or miss and you always want to see the other side...