194 karma · joined February 4, 2015
There are quite a few other ORMs for working with DBs in TypeScript (none of them providing the same type-safety guarantees that Prisma does though [1]).
In fact, we laid them out on a docs page [2] in case you want to learn which tool might be appropriate for your use case.
[1] https://www.prisma.io/docs/concepts/more/comparisons/prisma-...
[2] https://www.prisma.io/docs/concepts/overview/should-you-use-...
Just to clarify: Prisma is an open-source ORM [1] that's available via an npm package, so there really isn't a component that needs to be "hosted" here. (You might be referring to Prisma 1 which came with its own DB proxy server that was run via Docker, but Prisma 2 [2] doesn't have this Docker container any more and is "just" an npm library).
[1] https://github.com/prisma/prisma
[2] https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1
Prisma Migrate is entirely open source and works via a CLI. My understanding of "X as a service" typically includes some web service layer which is why I have a hard time following what you mean with your comment exactly.
Learn more: prisma.io/studio
As of today, we indeed only support relational databases (Postgres, MySQL, SQL Server, SQLite) but we are already working on a connector for MongoDB[1] and plan to expand to more DBs in the future, here's the open issue to support DynamoDB[2].
Hopefully Prisma becomes an option for you once we support your favorite DBs!
[1]: https://www.notion.so/prismaio/Prisma-Roadmap-50766227b77946...
> 1. Focus on integrating with tech I don't care about (e.g Next.js, GraphQL).
Just to clarify, we don't focus on any particular stack but Prisma can be used with any framework/library you like! Would love to learn more about what exactly gave you the impression that we'd focus on Next.js and GraphQL so that we can make sure folks don't misinterpret this in the future :)
> 2. Don't understand the business model. Seems like you want to lock folks into your ecosystem and then start charging for the surrounding products (e.g. Studio, Migrate).
We are commercial open source company, similar to companies like Hashi, Vercel or Gatsby. It's not a secret that we are a VC backed company and will need to make money eventually. In fact, we're currently working on a first version of a commercial cloud product that, among other things, will enable developers to collaborate better when using Prisma's open source tools in their projects. This commercial offering will be primarily targeted at teams and larger development organizations.
Nonetheless, the open source tools remain the core of our business and we're investing a lot of time and energy into them. Nobody will be forced to use the commercial services if all you need for your app is an ORM :)_
Really love the work they're doing, definitely check them out!
Also note that we've just opened up an early access program for Prisma Migrate [2] (which enables schema and data migrations), would love to hear your thoughts on our approach!
[2] https://www.notion.so/prismaio/Public-Documentation-for-Pris...
You can even combine Prisma with TypeGraphQL if you're building a GraphQL server that needs to access a databases. In that case, you'd use Prisma Client inside your TypeGraphQL resolvers to send database queries.
In fact, we are collaborating with the maintainer of TypeGraphQL to build an integration between Prisma and TypeGraphQL that will allow you to leverage information from your Prisma models when building your GraphQL schema! :)
> We are commited to building world-class open-source tools to solve common database problems of application developers. To be able to sustain our open-source work, we're planning to build commercial services that will enable development teams and organizations to collaborate better in projects that are using Prisma.
So, your hunch is correct that later down the road we'll invest into building commercial cloud services for teams and enterprises that are using Prisma's open source tool!
However, I believe that one thing that sets Prisma apart is the architecture with a _query engine_ [1] (implemented in Rust) that takes care of query planning and execution on top of which we can add lightweight, language-specific layers to bring Prisma Client to more programming languages. But you're definitely right that a generated database client is not a novel idea per se!
For example, we're already working on Prisma Client for Golang which is already available in alpha!
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
Prisma Migrate [3] is indeed still in the works, but we've shifted our focus a lot towards it now and you can expect major progress there over the next few weeks!
We definitely see folks using Prisma Client with production happily in production already, but I agree once Migrate joins the production-ready club, the Prisma package will be fully complete :D
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[2] https://www.prisma.io/docs/reference/tools-and-interfaces/in...
[3] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
With Prisma, we're setting out to build database tools that make developers more _confident_ and _productive_ [1] in their database workflows!
We're focusing on type-safety, intuitive data modeling, easy working with relations and overall simpler ways for achieving common tasks with your database.
We also wrote at length about what we believe the shortcomings are with databases tools in our documentation [2], would love to hear your feedback about our thoughts here!
[1] https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1/
Join live here: https://prisma.io/day
You can find the full recording here: https://www.youtube.com/watch?v=AnJxKWQG_fM
> The main problems I've run into have been around utilizing standard postgres naming patterns (snake case for tables and fields instead of camelcase) and mapping the names in the prisma schema. Ran into a handful of bugs related to having these mappings that have all been fixed since.
Better re-introspection flows are indeed very much on our radar and something that we want to tackle soon! Would be great if you could leave a comment with your use case on GitHub [1], so we can make sure to address it properly when planning and prioritizing new features! :)
> Better transaction support beyond just nested writes would be great and probably a requirement for a lot of apps.
Same here! It would be really helpful for us if you could share some details about your use cases for transactions in the feature request [2] so that we can incorporate them in our planning and design of the feature!
Prisma takes a fundamentally different approach by generating a database client that returns plain old JS objects. We've written more extensively about this topic in the docs: https://www.prisma.io/docs/understand-prisma/why-prisma
However, we do see a lot of folks using third-party migrations (like knex.js or indeed Sequelize) and then still get the benefits of Prisma Client [2] through introspection [3] for the time being. For non-critical applications we also already see lots of users who are trying out Migrate and help us improve it through constant feedback! I'd love to hear your thoughts on the current version so that we can make sure to consider your feedback and ideas for Migrate when building it out over the next few months.
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[2] https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1/...
[3] https://www.prisma.io/docs/reference/tools-and-interfaces/in...
Prisma is a database toolkit that's used by application developers to develop server-side applications in Node.js and TypeScript (e.g. REST APIs, microservices, gRPC calls, GraphQL APIs, ..., anything that talks to a database). The main tool Prisma Client is a query builder that's used to programmatically send queries to a database from Node.js/TS.
Hasura is a "GraphQL-as-a-Service" provider that generates a GraphQL API for your database. This GraphQL API is typically accessed by frontend developers. That setup can be great when your application doesn't require a lot of business logic and the CRUD capabilities that are exposed in the GraphQL API fit your needs (though I believe you can add business logic in Hasura by integrating serverless functions).
With Prisma, you're still in full control of your own backend application and can choose whatever tech stack you like for developing it (as long as it's Node.js-based, though Prisma Client will be in available in more languages the future)!
By the way, we also love GraphQL. We're currently brewing a new "GraphQL application framework" that can be used on top of Prisma. That way it will be possible to auto-generate resolvers for Prisma models to reduce the boilerplate you need to write, while still keeping the full control of your GraphQL schema.
You can learn more about this here: https://www.nexusjs.org/
> The problem with this tool, like every other multi-SQL-flavor-SQL ORM and query builder, is that it requires users to learn yet another language. In addition to Node.js and SQL, users need to learn the Prisma query language. This is not trival, and users that are already accustomed to working with SQL will need to relearn PrismaSQL.
I'm not sure I'd fully agree with this! The "other language" in this case is an intuitive and natural API (in Node.js/TypeScript) for querying data [1], so hopefully, there won't be much overhead to "learn" anything new. It should be rather the opposite and pretty straightforward to pick up, auto-completion and type-safety will also contribute to making the experience of querying data fluent without much learning overhead.
We specifically decided to abstract away from SQL because we found that many developers don't feel productive with SQL as their main database abstraction [2] (that's also why so many people roll their own data access layers in the end).
> I think the best approach to this problem is a single-SQL-flavor query builder that attempts to match SQL as closely as possibly while adding in the niceties of being able to pass in JavaScript objects instead of raw SQL strings. Lets be honest: raw SQL-in-JS is no fun.
It sounds like your thinking is generally aligned with ours actually! The main difference is that we concluded that the query builder shouldn't be SQL-flavored but just a natural API for any Node.js or TypeScript devs.
[1] https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1#...
[2] https://www.prisma.io/docs/understand-prisma/why-prisma#appl...
Also please read this Twitter thread between the lead Yarn maintainer and our CEO [2]. The gist is that we're very open to other approaches but this was the best we've come up with so far after 9 months of experimentation and lots of feedback from the community. This doesn't get easier by the variety of package managers out there and the custom workflows they sometimes employ (e.g. wrt pruning and caching). To put it in the words of our CEO: we'd be more than happy to embrace whatever package manager mechanism would enable this use case "more cleanly".
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [2] https://twitter.com/FredKSchott/status/1245053210852618246
While I can understand your sentiment, I don't think this is quite true! We've seen a number of companies very successfully adopt Prisma 1 – ultimately we realized though that the vision of building a new way for application developers to access their database can't be built on top of the JVM. At that point, we needed to make a tough judgement call and decided to rewrite Prisma in Rust. Needless to say that this was quite a challenge, but our engineers have done an absolutely outstanding job of managing this rewrite.
We certainly had a number of tough learnings, especially when it came to the variety of different DB schemas out there that we needed to support with our introspection. I'm really proud of the result though, we've built a strong and stable foundation that allows us to expand the functionality of our tools over time – this would not have been possible without the rewrite!
> With Prisma2, honestly disappointed as it is too little to show for. This is an ORM like library that supports only couple of databases with database migrations still in experimental state with broken links for workarounds[1]
Please recall that we're just launching into Beta. As I said, we now have the foundation to expand the functionality of our tools! You'll see a lot of exciting improvements and new tools from Prisma over the next few months!
Sorry about the broken links, I'm in the process of fixing most of them! In this case, the links point to the "Guides > Database workflows"-section which contains a number of helpful step-by-step tutorials for performing certain schema migrations (e.g. cascading deletes [1]) and using those with Prisma Client. (While these features are not supported by Prisma Migrate yet, you can still configure them in your DB and use Prisma Client for DB access).
[1] https://www.prisma.io/docs/guides/database-workflows/cascadi...
I think one thing that distinguishes Prisma (on the longer run) from a library like pgtyped is that Prisma will enable more database workflows than just database access. With Prisma Migrate, you can alter your DB schema and keep a migration history, Prisma Studio will enable lots of DB workflows on a GUI level, and Prisma Cloud will have great integrations for teams and larger scale organizations eventually.
All that being said, because Prisma is a DB toolkit, you can also pick and choose any tools you like from it. Nothing would e.g. speak against using Prisma Migrate to run your schema migrations but keep accessing your DB with pgtyped, in fact I think this would be an awesome combination :)