An ORM — the layer that turns objects in your code into SQL — can make the common path dramatically nicer. The trap is believing that because the application no longer writes much SQL, the database has stopped having opinions.
Use the ORM to remove repetition, not to remove database understanding.
ORMs are valuable because most queries are ordinary
Create user. Fetch order. Update status. Join related records. A typed client and built-in tooling for schema changes make that work fast and consistent.
That developer experience is valuable. Problems begin when the team assumes every database problem should be expressed through the ORM's most convenient shape.
Watch for accidental query explosions
Nested data fetching can create too many queries or pull far more data than the user needs. The code may look elegant while database time grows with every related row.
Count the queries your code actually generates on the paths that matter. Convenience should not hide how many there are.
Transactions need business boundaries
Do not sprinkle transactions around because several writes happen near each other. Define which writes represent one business action and what should happen if part of it fails.
An ORM's transaction API is only a tool. The architecture decision is where one business action starts and ends.
Indexes still belong to the product
Your schema should reflect how the data is actually read. A foreign key does not automatically create every index your workload needs. A generated migration cannot guess which query becomes critical at 10 million rows.
Watch the database metrics, and read the query plan for the paths that carry the most traffic.
Know when to use SQL
Reporting, aggregation, bulk updates, specialised Postgres features or carefully tuned queries may be clearer and faster in SQL. Using raw SQL selectively is not an ORM failure.
The failure is writing a 150-line application workaround because the team is afraid to speak to the database directly.
Treat migrations as production changes
Schema migrations — changes to the shape of the database — can lock tables, rewrite data, or break compatibility between the old and new versions of your app. Review them like code, and test the significant ones against realistic data volumes.
The migration generated in 200 milliseconds may run for much longer against a database that has been collecting customers for four years.
The balanced rule
Let Prisma make ordinary application data access pleasant. Let PostgreSQL remain PostgreSQL. Teach the team enough SQL to know when the abstraction is helping, and when it is hiding a real constraint.
Good abstraction gives you leverage. Great engineering knows where the abstraction ends.