Of course, at the point where you do need to break out beyond a single DB, life is more painful because you've got dependencies on the database all over the place...
It only starts to leak if everyone accesses the the DB through raw sql, mishmashing modules and creating insane dependencies.
Give each module ownership to a table and demand to only access it through there and the backend storage system becomes irrelevant
I believe you're being deeply naive about modules owning single tables. You forego relational integrity and almost the whole power of relational algebra if you take that approach. That's heaps of functionality to leave behind when you and one or two other guys need to crank out a feature a day.
I can see how you misunderstood me there however, it was admittedly poorly worded.
What I was talking about was basic data hygine as it's often called. If you need specific data, you define a clear way to get this data and only access it through that API. This can be a class, method or anything your language of choice prefers.
If you skip that step and directly access the DB everywhere in your code, you'll create another unmaintainable dumbsterfire as soon as your team goes beyond the initial programmers.
A startup needs all the options on the table because the alternative is they go out of business and there is no startup. This idea that we can enforce “good architecture” (subject to interpretation) with technology by isolating junior engineers with networking rules needs to at least be more transparent about its motivations.
For pieces to be able to be carved off, they already have to be autonomous.
What usually happens is that devs without experience in service architectures presume that service architectures are probably just the things they are used to seeing, ie: monolithic entities.
It's usually then that we hear things like "extract the product service". The problem is that product is an entity, and entities are the last thing to build services around. That's how we end up with distributed monoliths, and subsequently failed service architecture projects.
In order for an app to be able to transition to services, the app has to be designed this way from the beginning.
And yes, it's definitely possible to know what the model partitions should be up front. They're very natural divisions. But they can't be arrived at by looking through an entity-centric lens. And unfortunately, forms-over-data apps very rarely provide us with an opportunity to learn about the "other" way to do it.
Edit: Fixed a typo