Support DynamoDB

[nikolasburk]

This feature requests serves as a central place to discuss development and progress for the DynamoDB connector.

Please leave a 👍 and/or a comment in this issue if you'd like to see support for DynamoDB soon.

[amesas]

This one would be great, we use dynamodb for better "less-ops" scalability.
We connect to Posgres using Prisma, and dynamodb with custom code, we would love to use prisma as our only "connector" to data.

[fbjork]

Would be great to see DynamoDB support. Single Table design support would be amazing too.

[stewartjarod]

Single-Table, Adjacency pattern: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html#bp-adjacency-lists

[markthethomas]

This would be huge. Dynamo has a ton going for it - easy to run/scale, very very fast, offers stronger read/writes in the cases you want. Biggest drawback has always been the learning curve/lack of easier to work tools. if prisma supported this I would use it in a heartbeat over postgres. I love PG but for so many of my projects dynamo would check every box 💯

[IamManchanda]

Awaiting DynamoDB & MongoDB support would be GREAT GREAT GREAT if it happens ... thank you

I read this comment at mongodb issue #1277 (comment) and seems like you would be looking for a Rust Driver for connecting to dynamodb (similar to mongodb)

⏬ So would like to point to these links below ⏬

• https://rusoto.org/index.html
• https://crates.io/crates/rusoto_dynamodb

[softmarshmallow]

Any ongoing development for this?

[changtimwu]

AWS just announced PantiSQL over dynamodb. I guess this makes DynamoDB support easier.
https://aws.amazon.com/about-aws/whats-new/2020/11/you-now-can-use-a-sql-compatible-query-language-to-query-insert-update-and-delete-table-data-in-amazon-dynamodb/

[softmarshmallow]

Just for only query converting will be awesome since aws-sdk just sucks.

[adamdottv]

Any movement on this? I'd consider doing the heavy lifting here if it isn't already in the works.

[softmarshmallow]

@adamelmore sign me up too. I'me ready to commit. this needs to be done. AWS sucks, all other sucks. but we do need dynamodb,..

[ahmednawaz10p]

is it alive?

[cassidoo]

Any updates on this?

[softmarshmallow]

Since mongodb support is live as preview, naively seems that dynamodb would also be possible with same no-migration-support policy.

[mikestopcontinues]

@softmarshmallow DynamoDB has a very different design than mongo. Mongo is very similar to standard SQL in that you can have custom indexes, joins, etc. Whereas Dynamo requires thinking in a very strict hashKey/sortKey model, where the alphabetic order of your sortKey impacts how you can query data. This limitation impacts quite a lot of how the prisma feature set would map to Dynamo.

I'm here because I want it too, but it's not straight forward or easy. If nothing else, what it really suggests is that Prisma should allow custom adaptors, so that the Dynamo community could converge on the right way to integrate.

[flybayer]

At a Prisma event earlier this year, Prisma executives indicated Dynamo support almost certainly wouldn't come before next year.

[AllanOricil]

@softmarshmallow DynamoDB has a very different design than mongo. Mongo is very similar to standard SQL in that you can have custom indexes, joins, etc. Whereas Dynamo requires thinking in a very strict hashKey/sortKey model, where the alphabetic order of your sortKey impacts how you can query data. This limitation impacts quite a lot of how the prisma feature set would map to Dynamo.

I'm here because I want it too, but it's not straight forward or easy. If nothing else, what it really suggests is that Prisma should allow custom adaptors, so that the Dynamo community could converge on the right way to integrate.

And it is funny that lots of devs out there are modeling their data into dynamo as if it were exactly as mongodb. Lots of tutoriais do that. And there is even a lib like mongoose, but for dynamo.

[vincent-thomas]

Any updates? Are you guys considering adding dynamodb?

[MichalBunkowski]

Any updates?

[janpio]

No. An update would manifest itself in a comment in this issue. If that did not happen, we have nothing new to share about this feature. Feel free to comment with additional use cases or motivation about why you need the feature though, these are always useful for us.

[Thibault2ss]

We use dynamoDB and would love a prisma connector, because we love prisma ❤️

[alexmarqs]

@janpio a good motivation for this is the bad experience (DX) when dealing with dynamodb client. Additionally, you don't see any good ORM for this database type out there when comparing it with the API provided Prisma. A lot of companies are using AWS Serverless architectures with dynamodb as its persistence layer. Technically, probably it's not straightforward / easy due dynamodb design/architecture but it would be great to have some support for this 👍 , game-changer!

[junaway]

Hi all,
For those who are waiting for Prisma to support dynamodb, maybe this will help you ? https://github.com/sensedeep/dynamodb-onetable
(You can still use it even if you don't abide by the single-table design motto.)

[climber2002]

@junaway I'm using dynamodb-onetable and it works great so far

[cyriaque-ovaga]

Feature ?

[gultyayev]

We use dynamoDB and would love a prisma connector, because we love prisma ❤️

@Thibault2ss AWS explains in some of their docs that we should not use dynamodb like we usually work with docs in mongodb, or even tables and relationships in sql. I don't believe Prisma would be suitable for creating this abstraction layer you want because it does exactly what amazon recommends developers not to do.

Could you please share the links to the statements?

[AllanOricil]

We use dynamoDB and would love a prisma connector, because we love prisma ❤️

@Thibault2ss AWS explains in some of their docs that we should not use dynamodb like we usually work with docs in mongodb, or even tables and relationships in sql. I don't believe Prisma would be suitable for creating this abstraction layer you want because it does exactly what amazon recommends developers not to do.

Could you please share the links to the statements?

Here you can read about it
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html

You have to understand how dynamo differs from mongodb in terms of data organization and optimizations.
Adding prisma to "facilitate" creating multiple tables will surely end up creating a bad no soql database architecture. I'm pretty sure rooks will apply normalization as soon as possible and create lots of tables. Making the project extremely more expensive, and less scalable.
There are some videos I watched from an engineer from aws explaining how to design an app using a single table to store multiple entities. It comes down to using the primary key to index your entities (tables). When I find this video I can update my comment.

Update: still couldn't find the video I watched but here is another one which a guy explains how and why to use a single table design: https://youtu.be/KYy8X8t4MB8

Another video showing an example of denormalization into a single dynamodb table https://youtu.be/Dqa4kG5yBMk

[handletastic]

I would love to see this happen. I know that there are quite a lot of blockers for this to happen. Anyone knows any latest movements?

[ahmad-ali14]

although I would like to use Prisma with ddb, it just feels weird, and I don't think that the relational nature of prisma suits dd.

[jayalfredprufrock]

I agree that managing dynamodb "relationships" doesn't feel like a good fit for Prisma and if you are designing complex single-table schemas to maximize performance for ultra specific use cases, a generic layer on top like Prisma would only get in the way. That said, I often use dynamodb in microservices as a simple distributed hash map because of its speed and low cost. Just having a strongly typed client that could fetch and update documents by partition keys and GSIs would be incredibly helpful.

This may have already been thrown out as well, but DynamoDb got support for PartiQL a while back. I have no experience with it so can't comment on what exactly that brings to the table, other than implementing a driver against this "SQL compatible language" could enable other types of data stores with low effort, but don't quote me on that.

[eranartzi]

I think a lot of people use ddb the same way they use mongo, so having prisma support ddb would be amazing

[Hatko]

It'd be great to support DynamoDB

[miguelvelasquezdev]

is there some PR about that? 👀

[dahari87]

So many people i know would love to have this connector.

[jeremygottfried]

I worked with DynamoDB for a while and created a custom ORM to make it more usable, but it works using data copies, so query consistency is a big issue. Having a declarative API like prisma would be great, but I'm guessing it would be quite a challenge to make it usable with prisma. I personally concluded that the extra cost associated with maintaining such a database is not worth the savings if you need consistent, relational data. However, it's great for non-conventional data structures.

[emilshr]

Adding another comment to increase the issue relevance!

[gersongams]

please 😭

[jeremygottfried]

Here's an example of why mapping relational data in DynamoDB is such a challenge. To get something similar to an SQL table with relationships, you create a bunch of indices, which are really copies of the data with different keys. Write transactions become expensive if you want to query a lot of columns and relationships, and you're also paying the extra expense of storing data copies. Updating or deleting a row becomes a challenge, because you also have to update every index along with the main data. One of the selling points of DynamoDB is that it's low level and dynamic, so creating a declarative API may not be worthwhile.

      const TransactItems = [
        ...additionalTransacts,
        {
          Put: {
            Item: { ...instance, ...indices, ...globalSecondaryIndices },
            TableName,
          },
        },
        ...globalIndices.map((index) => ({
          Put: {
            Item: index,
            TableName,
          },
        })),
        ...belongsToEntries.map((index) => ({
          Put: {
            Item: index,
            TableName,
          },
        })),
      ];

One dev might want to store the entire row (*) with the email index, while another dev might only need the user name and PK with the index, so how do you allow that level of customizability and still have a usable API? DynamoDB works best when you design tables and indices based on the data you need, rather than trying to fit it into a pre-made API structure.

[thibauld]

+1 I'd love if we could use prisma with dynamodb!

[me2resh]

Would love to see this planned in the roadmap.

[tankcdr]

Definitely would prefer to be backed with DynamoDB such that I can integrate with the rest of my stack.

[AdrianBalcan]

Totally understand that can be a different approach in the implementation and also in the use, but this would be such a great feature. I believe that once this implementation will get mature enough, Prisma will be able to scale a certain architecture of multiple API's which we can see that many tools and companies are heading towards.

[akshay-99h]

I have received a project recently. It has DynamoDB as database. I am accustomed to working with prisma all the time for most of my projects. I know some of the best people out there are working on this repo. I just want to know if an official support for DynamoDB will be released soon.

Update: Just checked #1676 (comment) :(

[dvins]

As pointed out by others DynamoDB is for all intents and purposes orthogonal to Prisma. It just does not have the same schema guarantees and especially query capabilities of say, MongoDB. In lieu of that, highly recommend Dynamoose as a great framework to use when working with DynamoDB. It adds the structure, type safety, and other modeling guard rails and makes a huge difference vs. hand crafted calls.

Dynamoose
https://dynamoosejs.com/getting_started/Introduction
https://github.com/dynamoose/dynamoose

[dtbayles]

i beg. this would be a really hot feature for the Prisma community especially since Dynamodb is an extremely common startup db given its low cost. If devs can at least have some prisma infrastructure in their projects early on, then when they need to adjust to another db as they scale, they'd be much more incentivized to just continue using Prisma and finding another db that is supported.

My particular use-case is that I have a Raspberry Pi hosting my Next.js app offline. When users connect, they are interacting with the app and a local Postgres db. This is for an NGO and distributed to remote areas where access to internet is already limited and expensive. On the live site, however, using an RDS instance or other live Postgres instance is just not justifiable to pay for yet as we are still growing. We aren't doing anything too complex for DDB but now we are faced with writing the db queries for both offline and online versions until we can migrate them all over to using the same prisma queries

I understand that the postgres and ddb queries wouldn't be the same. but having them both at least use the same ORM makes it a whole lot cleaner and easier to maintain.