HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
prisma
orm
TypeScript2018–2026
prisma / orm

orm

The Prisma ORM: write your application in TypeScript with human-readable queries instead of SQL. Host your database on Prisma Postgres and your app on Prisma Compute.

49Distinct people
74Mentions
1Explicit recommenders
47.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The Prisma ORM: write your application in TypeScript with human-readable queries instead of SQL. Host your database on Prisma Postgres and your app on Prisma Compute.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I love Prisma and am a huge fan of Nexus[1] in particular. But it's interesting that you mention transactions as Prisma does not yet support long running transactions[2]. I…

string used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:01:12 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year74 dated mentions

Observed mentions: 2018-12-03 19:57:14 UTC to 2026-09-16 17:43:54 UTC.

0510152018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 16 mentions; 1 submissions, 15 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 11 mentions; 1 submissions, 10 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 14 mentions; 2 submissions, 12 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 8 mentions; 2 submissions, 6 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC606
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC16115
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC10010
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC11110
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC14212
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC505
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC826
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

What Hacker News says

6 sources
What this article misses IMO is a clear distinction of the various abstractions layers an ORM can provide, most importantly these two: - Heavy ORMs: Object-oriented mapping layers that map classes to tables. A record is represented as an object that not only carries data but also implements various behaviours for storage, retrieval, serialization and deserialization of its own data, sometimes it also implements business/domain logic. Examples: ActiveRecord, EntityFramework, Hibernate, Sequelize, ... - Lightweight query builders: Lightweight, programmatic abstractions on top of SQL. Examples: knex.js, pypika, ... There are issues with both approaches. Heavy ORMs Heavy ORMs make it seem like a developer doesn't need to know SQL to work with a database. They help to get a project off the ground quickly, but as a project grows and requirement
Read the rest
s become more complex, they often generate slow queries or generally lack capabilities to express the right queries. After all, a developer will be forced to understand what's going on in the SQL layer underneath, spending a lot of time debugging and understanding the generated queries, often without the possibility to optimize them. The premise of "not knowing SQL" and productively working with database longterm has just been proven wrong in so many cases (I feel like everyone has been burnt by an ORM at least once in their dev career...). Lightweight query builders Lightweight query builders on the other hand don't try to abstract too much away from SQL. Their APIs typically use SQL terminology and they're not trying to hide the fact that they're working with a database. Coming from an application developers perspective, there still is the drawback that you must have a solid understanding of SQL to work with them efficiently. Another issue that these query builder APIs typically aren't type-safe. There's no static analysis that can help identify typos or other issues in the DB queries you're building. In terms of developer experience, they lack features like autocompletion for DB queries. Personally, I still prefer query builders over heave ORMs since I get more control. Time for a plug: I work at Prisma where our mission is to make it easier for application developers to work with databases by providing developer-friendly, efficient and performant abstractions and tools for working with database! We're currently building the Prisma Framework [1] which consists of two main tools: - Photon [2]: A lightweight, auto-generated and type-safe database client - Lift [3]: A tool for declarative data modeling and database migrations You can learn more about both tools in this blog post: https://www.prisma.io/blog/announcing-prisma-2-zq1s745db8i5/ Both tools are based on the Prisma schema [4], a declarative abstraction over your database schema that serves as foundation for the generated Photon API. Lift migrations work by mapping the Prisma schema to your database schema. We also build a ton of other nice tools and libraries that simplify database workflows (such as Prisma Studio, a database GUI) or integrations with API layers, such as GraphQL Nexus [5] for building type-safe GraphQL APIs without boilerplate. To get started, check out this tutorial: https://github.com/prisma/prisma2/blob/master/docs/tutorial.... [1] https://github.com/prisma/prisma2 [2] https://photonjs.prisma.io/ [3] https://lift.prisma.io/ [4] https://github.com/prisma/prisma2/blob/master/docs/prisma-sc... [5] https://github.com/prisma/nexus
In ORMs Are Backwards
I work at Prisma and this is one of the questions we're currently hearing the most (we'll actually publish a blog post about this exact question soon). Generally, think of Prisma as a suite of database tools that simplify workflows in three different areas: ● Database access / ORM (lightweight, auto-generated and type-safe database client for various languages) ● Declarative data modelling and migrations ● Data management with modern admin UI I think it also differs from traditional ORMs in that it supports multiple databases. We see a trend that many modern apps are built on top of a variety of databases, it might use Posgtres, Elastic, Mongo and Neo4j all at the same time for different purposes. We are embracing this and with the Prisma client it will be possible in the future to access all these data sources in a single, coherent and t
Read the rest
ype-safe API. Feel free to check out our roadmap to get an idea of what we're working on: https://github.com/prisma/prisma/blob/master/ROADMAP.md
In Prisma – Database tools for modern application development
First time learning about Hasura. Looks really promising with the built-in _live queries_ support, which Prisma has not yet implemented (they only have subscriptions): https://github.com/prisma/prisma/issues/1205 EDIT: Never mind, looking at the docs, it looks like they also only support subscriptions... It's understandable to not have support for live queries yet, as it's still a very under-explored territory, but it's still misleading marketing on their part because they explicitly call out support for subscripts _and_ live queries on their website. Curious how Hasura tackles the N+1 problem for efficient querying in GraphQL? Prisma uses a built-in dataloader implementation for this but I couldn't find anything about query optimization in the Hasura docs. Also, in the docs on pagination: https://docs.hasura.io/1.0/graphql/manual/queries
Read the rest
/pagination... I'm only seeing examples of offset-based pagination. Is cursor-based pagination on the roadmap as well?
In Prisma – Database tools for modern application development

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.