> your app being quite tightly coupled with the database

I mean, this is the case any time your app talks directly to a database

Think I was using the wrong terminology. What I meant is that your ORM code in the app needs to reflect your database pretty much exactly, otherwise you can get unwanted migrations.

Which is in most cases desirable, but for example if you want to use database features that SQLAlchemy/Alembic don't (yet) support it can get a bit messy and/or require some manual plumbing to keep getting the migrations you want.

Only if your DB is purely a way of keeping your objects warm, otherwise you can design your DB with the business in mind, the app with the apps domain in mind, and an adapter between the two. Layer of abstraction but might help BAs work against the database and not be stumbled by application specific things that affected the design. Depends on the system of course!

Then your "app" is the adaptor, and the tying still applies.

why would you ever add a layer between you and the db?

Some DBs have inherent limitations and you need to design something to get around them. Sometimes you have many apps and you don't want to reinvent the wheel to support what are otherwise standard accesses of a database. Sometimes it's a "special" database which makes this more convoluted, or perhaps you need to implement things like a gradual back-off retry to prevent swamping the backend. Sometimes you don't want to have to patch every app that uses the database if a database change is breaking. Sometimes you want to prevent developers from abusing your database, provide more fine-grained access control, prevent poorly researched queries which can kill performance, etc. Sometimes you're talking to more than one db.

Personally, I would start writing the abstraction as soon as I plan to have more than two apps.