Schema ownership
Model constraints and relationships where they remain enforceable, not only in application forms.
Application data layer
Prisma Data Access Engineering.
An ORM improves developer feedback, but it does not replace database design, query analysis, transaction reasoning, or migration discipline.
How we use it
We use Prisma when its schema, generated client, and migration workflow improve clarity between a TypeScript application and relational data. Database-native capabilities remain available when the abstraction is not the right fit.
Architecture decisions
The questions that shape the implementation
Query shape
Select only required fields and inspect the actual SQL behavior of important paths.
Transactions
Define which changes must succeed together and keep transactions short.
Migration safety
Separate schema expansion, data backfill, application change, and cleanup when zero-downtime evolution requires it.
Engineering practice
What disciplined use looks like
Explicit constraints and indexes
Narrow query selection
Reviewed generated migrations
Expand-and-contract changes
Integration tests against a real database
Database metrics alongside application traces
Failure modes
What we actively design against
N+1 query behavior
Treating generated migrations as automatically safe
Long interactive transactions
Hiding database-specific requirements behind the ORM
Appropriate use cases
TypeScript SaaS platforms
Business management systems
Customer portals
Operational dashboards
Admin applications
Relational product backends
Technical questions
Does Prisma replace knowledge of SQL?
No. Reliable systems still require understanding relational modelling, indexes, query plans, locks, transactions, and database operations.
Can Prisma support complex systems?
Yes, while allowing raw or database-native approaches for queries and capabilities that are clearer outside the ORM abstraction.
Related expertise