A Migration Journey from Amazon DynamoDB to Yugabyte YSQL and Hasura
summary
Migration replaces Apollo Server + Amazon DynamoDB with Hasura plus Yugabyte YSQL and adds Prisma as the canonical data layer, claiming better developer experience, built-in GraphQL and global replication. Pain points: single-table design required many cryptic sort-keys and indexes; solution uses bulk table scan then a delta sync via DynamoDB streams to load and catch up. Incremental rollout uses feature flags per service; a small generator converts Prisma schemas and actions into Prisma→Hasura metadata tool and the stack is reported working and faster to iterate.
AI-written summary · about
chapters (18)
- 0:00Intro
- 1:56About BRIKL
- 2:41Data model
- 4:09GraphQL Voyager
- 4:51DynamoDB Strength & Weakness
- 7:21GraphQL to DynamoDB
- 10:16DynamoDB Single Table Design
- 12:08Dynamo DB vs Yugabyte
- 13:36More Indexes!
- 14:20DynamoDB vs Yugabyte
- 15:04Requirements to switch
- 16:56Yugabyte & Hasura
- 19:13NoSQL to Postgres. DB Migration
- 22:17DynamoDB Migration approaches
- 23:43BRIKL DB Migration approach
- 26:24Tooling - Prisma/Hasura
- 29:47Tooling - Hasura actions
- 30:10Tooling - Hasura metadata
related talks
20mSuperpowers Developers: GraphQL + DistributedSQL
28mDisrupting the Status Quo with Distributed SQL to Deliver Data-Driven Solutions
27mAn API First Approach to Adopting a Distributed SQL Database
19mBuilding Planet Scale Cloud Native Apps with GraphQL & Distributed SQL
24mScalable and Resilient GraphQL Subscriptions with Distributed SQL Databases
27mSparking our way to YugabyteDB: Our journey from ScyllaDB to
22mUnlocking API Potential with Hasura's GraphQL Engine
17mHasura: a GraphQL back-end in minutes