---
title: "Prisma | Skills We Assign For | Azendo"
description: "Prisma as a typed ORM — what schema-driven types prevent, where the abstraction leaks, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/prisma/"
---

[Skills](https://azendo.co/skills/) Data stores and query 

# Prisma.

Prisma is a TypeScript ORM that generates a fully typed client from a schema file and manages migrations from the same source. Its distinguishing property is type safety that reaches the database: a query selecting a column that does not exist fails at compile time rather than in production.

## Where Prisma fits on a long engagement.

Prisma's value is concentrated at the boundary between application and database, which is historically where type safety stops. A renamed column normally becomes a runtime error discovered by a user; with a generated client it becomes a build failure discovered by the person who renamed it. On a schema that changes regularly that is a meaningful reduction in a whole class of defect.

The abstraction leaks in the usual places. Complex analytical queries, database-specific features and fine-grained query tuning all push toward raw SQL, and Prisma's generated queries are not always what an experienced hand would write. Treating it as the default with a documented escape hatch, rather than as a rule, is the approach that survives contact with a real workload.

## What an assigned team does with Prisma.

Migrations are the part of an ORM that becomes dangerous with unfamiliarity. A migration that locks a large table in production is a straightforward mistake to make and an expensive one to make twice, and avoiding it depends on knowing the data volumes rather than knowing the tool.

That product-specific knowledge is exactly what a standing assignment accumulates and rotating capacity discards. Where the schema and its volumes are the real constraint, that capacity is scoped under [data engineering outsourcing](https://azendo.co/services/data-engineering/) alongside the application work.

## What we use Prisma for.

* Schema changes caught before release A generated client that turns a column rename into a compile error rather than a production incident.
* Migrations safe on real data volumes Changes planned against the actual table sizes, so a deploy does not take a lock nobody anticipated.
* One schema across services Several TypeScript services sharing generated types, so a model change cannot silently diverge between them.

## How Prisma capacity is assigned.

Prisma work is assigned inside backend capacity under [outsource software development services](https://azendo.co/services/software-development/), with migration safety treated as part of the definition of done.

## Roles we assign Prisma for

* [Full Stack Developer Software development](https://azendo.co/services/software-development/full-stack-developer/)

## Service lines it sits in

* [Software development](https://azendo.co/services/software-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in data stores and query

* [SQL — skill we assign for](https://azendo.co/skills/sql/)
* [PostgreSQL — skill we assign for](https://azendo.co/skills/postgresql/)
* [MySQL — skill we assign for](https://azendo.co/skills/mysql/)
* [MongoDB — skill we assign for](https://azendo.co/skills/mongodb/)
* [Snowflake — skill we assign for](https://azendo.co/skills/snowflake/)
* [BigQuery — skill we assign for](https://azendo.co/skills/bigquery/)
* [Redis — skill we assign for](https://azendo.co/skills/redis/)
* [Postgres — skill we assign for](https://azendo.co/skills/postgres/)

## Tell us what your roadmap needs Prisma for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)