DEV Community

HamzaNab-Dev
HamzaNab-Dev

Posted on

Why I Used Both Amazon Aurora AND DynamoDB in the Same App — AWS H0 Hackathon

#aws #dynamodb #postgres #h0hackathon

For the AWS H0 Hackathon I built ChatScroll — a personal
AI knowledge library. I made a deliberate architectural
choice to use TWO AWS databases for different reasons,
and I want to explain why.

The Core Insight

Not all data is the same. Different data has different
characteristics that make one database better than another.

Amazon Aurora PostgreSQL — The Knowledge Layer

ChatScroll stores "Scrolls" (saved AI answers) in Aurora
PostgreSQL because they need:

  • Complex queries — filter by folder, search by similarity, rank by relevance
  • Relational integrity — scrolls belong to folders, folders belong to users
  • Vector search — pgvector extension for semantic similarity using 3072-dim embeddings
  • Full-text search — tsvector for keyword matching
  • Tree structures — ltree for hierarchical folder paths

Aurora is perfect for this — it's PostgreSQL with
production-scale reliability and three powerful extensions
working together.

Amazon DynamoDB — The Chat Layer

Chat messages have completely different characteristics:

  • High volume — every message in every conversation
  • Simple access pattern — always fetched by conversationId
  • Time-ordered — always read chronologically
  • Auto-expiring — old messages should disappear after 90 days

This is a perfect DynamoDB use case:

PK: conversationId (String)
SK: {timestamp}#{messageId} (String)
TTL: expiresAt (Unix epoch, 90 days)
Capacity: PAY_PER_REQUEST
Enter fullscreen mode Exit fullscreen mode

The composite sort key enables chronological reads and
time-range queries in a single DynamoDB operation. TTL
auto-expires messages with zero infrastructure — no cron
jobs, no manual deletes.

The Dual Database Pattern 

Aurora PostgreSQL          DynamoDB
─────────────────          ────────
scrolls + embeddings  │    chat messages
folder hierarchy      │    composite sort keys  
user accounts         │    90-day TTL
conversation metadata │    pay-per-request scale
complex queries       │    simple key-value access
Enter fullscreen mode Exit fullscreen mode

Aurora owns structure and search.
DynamoDB owns the high-volume message stream.

Each database doing what it's best at.

What I Learned

DynamoDB key design is everything. The
timestamp#messageId sort key pattern unlocks
chronological reads, time-range queries, and uniqueness
in a single attribute. Getting the key design right
upfront saved me from any schema migrations later.

Aurora pgvector at 3072 dimensions has index limits.
Both ivfflat and hnsw indexes cap at 2000 dimensions on
Aurora's pgvector version. For a personal knowledge base,
exact search works perfectly and is simpler to maintain.

Serverless v2 auto-pause is a feature. Aurora
Serverless v2 auto-pauses when idle — zero cost during
development and low-traffic periods. Perfect for a
hackathon prototype.

The Result

A production-grade dual-database architecture where:

  • Aurora handles all the complex relational and vector search operations
  • DynamoDB absorbs all the chat message write volume
  • Each database is used exactly as it was designed to be

Try ChatScroll: https://chatscroll.vercel.app
AWS Architecture deep dive: https://chatscroll.vercel.app/aws-showcase

I created this content for the purposes of entering
the AWS H0 Hackathon.

H0Hackathon #AWS #Aurora #DynamoDB #Vercel #H0Hackathon

Top comments (0)