Data

Prisma Development

We use Prisma where a typed schema and a managed migration history earn their place, and drop to SQL where the query is the interesting part.

Usage

What we build with Prisma

Rationale

One schema produces the types
Model definitions generate the client types, so the shape of a record is checked wherever it is used rather than asserted.
Migrations are reviewable
Each change is a versioned file in the repository, applied in order in the pipeline. Ad hoc schema changes are how environments drift apart.
Relations are readable
Nested reads express intent clearly, which keeps ordinary queries short and reviewable.

Practice

Raw SQL where it is better
Aggregations, window functions and recursive queries are written as SQL. Forcing them through a query builder produces slow and unreadable code.
Transactions for multi step writes
Anything that must be all or nothing runs inside an interactive transaction with the isolation level stated rather than assumed.
Tenant scoped access helpers
A thin layer applies the tenant filter, so no query reaches the database without it and reviewers can see that at a glance.
Explicit selects
Queries select the fields they need. Returning every column by default is how a list endpoint quietly starts shipping a megabyte.

Related work

These projects share relevant engineering concerns. Each study identifies its documented technology choices.

Solutions

Writing

Tell us what you are building and what it has to connect to. We will come back with an approach, a scope and what it would take.