I think you are putting focus on the wrong values. In agile, business value is in focus. You create a product in order to deliver business value to some end users.
If you create the persistence layer late, or make it up along the way is your strategy for delivering business value to the customer. I don't believe that the term "agile" itself dictates if you should do one or the other.
The point of view about deferring data storage strategy is advocated in this presentation by Robert C. Martin (one of the authors of the agile manifesto).
It is a very good presentation, I can recommend that you watch it.
But I disagree with it! At least to a degree.
I do not believe that you can call a user story for "Done", if the user story involves data that should be persisted, and you don't actually have any type of persistence implemented.
If the product owner decides that now is the time to go live, you are unable to do that. And if you haven't started implementing persistence until late in the project, you also have no information about how long it would take to implement the persistence layer, leaving it a major project risk.
The agile projects I have worked on have not deferred the data access strategy. But it has been decoupled, allowing us to change it along the way. And the entire database schema is not designed up front. Tables and columns are created along the way as they are required in order to implement the user stored that, in the end, deliver business value.