[moomin]

I have, in fact, read the article, and they are _vastly underestimating_ the importance of those downsides. For instance, I once dealt with an issue that involved adding a column to a table, which they think shouldn't be too bad, that took two actual years to resolve because of all of the infrastructure built on top of it that bound directly to the table structure.

[DrScientist]

But surely the problem is with the infrastructure that can't deal with an extra column - not the db/table itself?

If all the users of an API were bound to the shape of the data returned, but you wanted to add an extra field, you'd have exactly the same problem surely?

Sounds like the problem was with too much magic in the layers above - as in the end the shape of the data returned from a query on a table is up to the client - you can control it directly with SQL - in fact dealing with an extra column or not is completely trivial in SQL.

[moomin]

I mean, exactly, that’s why this is a bad idea. Adding a column is simple, having your DB be your API is madness. The more magic you add, the worse it gets.

[DrScientist]

I think you are mixing two problems - having the part of the DB exposed, and whether people then build brittle stuff on top.

My point is that if people build brittle stuff on top that's not a problem of the DB being accessible per se.

That could just as easily happen against an API.

I assume you had was some problem with ORM's and automatically built data structures etc - I would argue that's a problem with those, not with the DB.