Depends what "disconnected" means. Before Object Relational Mappers came along, you wrote a load of SQL in Stored Procs or in some other framework. This was super tight coupling because updating the database version could ruin everything. Not everything was in compiled code, so it was hard to track.

If you use an ORM (such as Entity Framework I'm about to mention but there are lots) for the write/mutation part then the ORM provides you with that disconnect. You might want to use a different mapper for read, that allows you to write efficient SQL that meets particular needs.

For example, a few years back in .NET Framework I swapped a system that designed/built on Sql Server to run on Postgres. Took me a few days. I didn't change any domain logic during that time. I'd say that the ORM provided a disconnect between the actual persistence and my domain.

I do like a disconnect between my API and the database so that I am able to update the database without causing issues with consumers of my API. That usually requires some kind of mapping but only once. My preferred model right now is a CQRS (don't need ES) using Paramore's Brighter command pattern.

That's for an RDBMS, I think with schemaless/DocDB you can go even further but then the code that loads out the data needs to deal with missing values. That's a different sort of constraint.

I hope that helps, I think I'm rambling now.