Why I replaced DynamoDB with Aurora PostgreSQL Serverless v2 for an ad-ops monitoring workload

On February 14, 2026, Meta started enforcing health-data restrictions that broke pixel-based lower-funnel conversion tracking for DTC telehealth advertisers. No purchase events. No lead events. Attribution for GLP-1, TRT, hair-loss, mental-health, and compounding-pharmacy campaigns went dark overnight.

I run paid acquisition for Bliss Health. At 11 PM the night it shipped, I watched a single ad set burn $4,200 — frequency at 4.7, CTR collapsing, conversion data delayed by Meta's own pipeline. The alert that should have fired four hours earlier didn't exist.

When attribution dies, you need leading indicators: frequency saturation, CTR trend against a rolling baseline, CAC vs. median. These metrics are computable from raw delivery data the Meta Marketing API still returns in real time. The tool I wanted didn't exist, so I built it for the H0 hackathon.

Ad Engine: polls Meta + Google every 15 minutes, runs 5 alert rules, sends each fired alert to Claude Sonnet 4.6, which returns a schema-enforced JSON diagnosis with three ranked actions tagged by urgency now / today / this_week). Operator gets a 30-second decision instead of a 6-hour investigation. Live at runadengine.com.

The architecture decision I want to talk about is the database. H0 lets you pick between Amazon Aurora PostgreSQL, Aurora DSQL, and DynamoDB. My original plan was DynamoDB. I swapped to Aurora Serverless v2 mid-build. Here's the actual decision matrix.

The decision matrix

DynamoDB wins decisively for high-velocity single-item writes where you can draw the complete access-pattern diagram before writing the first line of application code: session stores, leaderboards, IoT telemetry ingestion, shopping-cart state. If that's your workload, DynamoDB is the correct answer and Aurora is overkill.

My workload is the opposite. Every dashboard render is a multi-table join (accounts × campaigns × ad_sets × ads × insights_hourly × alerts) with time-series windowing for sparkline charts and 7-day baselines for the alert rules. The access pattern evolves every time I add a new rule or a new chart.

That's an Aurora workload.

The schema decision

The hardest part of this swap was the schema, not the swap itself. Here's the insights_hourly table that does most of the work:

export const insightsHourly = pgTable(
  'insights_hourly',
  {
    id: serial('id').primaryKey(),
    level: text('level').notNull(),         // 'campaign' | 'ad_set' | 'ad'
    entityMetaId: text('entity_meta_id').notNull(),
    accountMetaId: text('account_meta_id').notNull(),
    windowStart: timestamp('window_start').notNull(),
    spend: numeric('spend'),
    impressions: integer('impressions'),
    clicks: integer('clicks'),
    conversions: integer('conversions'),
    revenue: numeric('revenue'),
    ctr: numeric('ctr'),
    frequency: numeric('frequency'),
    cpa: numeric('cpa'),
    roas: numeric('roas'),
    // ...
  },
  (t) => [
    uniqueIndex('insights_entity_window_idx').on(
      t.level,
      t.entityMetaId,
      t.windowStart,
    ),
  ],
);

The composite unique index on (level, entity_meta_id, window_start) is doing more work than it looks. It lets the sync function — which is the same cron job that runs every 15 minutes, every reseed during local dev, and every backfill from the Meta API — write with INSERT ... ON CONFLICT DO NOTHING. The pipeline becomes idempotent without a single line of dedup code.

With DynamoDB, I'd implement this idempotency in application logic (conditional writes against a hashed primary key), and every consumer of the table would have to know about the dedup logic. With Aurora + a unique index, every consumer just queries; the database handles it.

The query that justified the swap

The frequency_high alert rule needs to detect creative fatigue — frequency above 4.0 for a sustained period — without falsing on the random spike that any normal ad set hits once. The rule needs a 7-day baseline:

SELECT
  entity_meta_id,
  window_start,
  frequency,
  AVG(frequency) OVER (
    PARTITION BY entity_meta_id
    ORDER BY window_start
    ROWS BETWEEN 336 PRECEDING AND 1 PRECEDING
  ) AS freq_7d_baseline,
  AVG(ctr) OVER (
    PARTITION BY entity_meta_id
    ORDER BY window_start
    ROWS BETWEEN 336 PRECEDING AND 1 PRECEDING
  ) AS ctr_7d_baseline
FROM insights_hourly
WHERE level = 'ad_set'
  AND account_meta_id = $1
  AND window_start >= NOW() - INTERVAL '7 days'
ORDER BY entity_meta_id, window_start;

336 = 14 days × 24 hours. The window function looks back at the 336 prior rows (per entity) and gives me the rolling average against which the current frequency is judged. The frequency_high rule fires when the current value exceeds 4.0 and exceeds the baseline by some margin.

This is exactly the query I would have implemented as a Lambda-mediated three-step process against DynamoDB. In Aurora it's one statement, the planner handles the indexing, and adding a sixth or seventh alert rule is a copy-paste exercise instead of a re-architecture.

Serverless v2 pricing math

Min capacity 0.5 ACU, max 1.0 ACU for this workload. At 0.5 ACU in us-east-2 the cluster runs about $43/month at full idle. The ACU autoscaler bumps capacity for ~30 seconds when the 15-min cron fires and the alert engine kicks off concurrent Claude calls, then drops back to floor.

For a pre-revenue product that polls every 15 minutes — most of those polls being no-op writes against an already-current dataset — provisioned Aurora would have wasted credits constantly. Serverless v2's ACU scaling is exactly the right shape for cron-driven bursty-but-predictable workloads.

The Vercel Fluid Compute connection pooling story

This is the part that took the longest to figure out. Aurora connections are not free. The Postgres protocol does a real TCP + TLS + auth handshake; opening a new connection every Vercel function invocation would saturate the cluster's connection limit in minutes.

The solution is postgres-js with two specific flags:

import postgres from 'postgres';

const sql = postgres(process.env.DATABASE_URL!, {
  prepare: false,     // Vercel Fluid Compute instances reuse — no per-statement state
  max: 1,             // one connection per warm instance, not per request
});

prepare: false is critical because Vercel's Fluid Compute reuses function instances across concurrent requests, but stateful prepared statements would leak between them. max: 1 keeps one warm connection per function instance, which Fluid Compute then reuses for every request that lands on that instance.

The net result: I get connection pooling for free because Fluid Compute does instance reuse, and I don't need RDS Proxy or an external pgBouncer. For a hackathon-scale deployment, this saves real complexity.

Why not Edge Functions

For completeness: Vercel offers Edge Functions that run on a V8 isolate at the edge. They're faster to start than Node functions. I considered them.

I rejected them because:

1. The Anthropic AI SDK needs Node.js APIs (streams, crypto)
2. postgres-js needs raw TCP socket access, which V8 isolates don't expose
3. The dashboard's 14-day windowed queries take ~200ms — the Edge-vs-Node latency difference is rounding error against query time

Fluid Compute (Node.js, instance reuse, no cold-start tax on warm instances) is the correct primitive for this workload. Edge is correct when you're returning cached HTML at the edge or doing lightweight token validation.

What I'd reach for DynamoDB for (the honest disclaimer)

I want to be specific about where DynamoDB is the right answer, because nothing in this article is "Aurora always wins":

• High-velocity single-item writes with a known primary key shape (think IoT telemetry, click-stream ingestion, session tokens, leaderboards, rate-limit counters)
• Stable, pre-planned access patterns where you can draw the complete GSI layout before writing application code
• Multi-region active-active where you need writes accepted in any region with eventual consistency, not coordinated joins
• Workloads where you genuinely don't need joins or window functions — and where adding them would require a redesign anyway

If any of those describe your workload, DynamoDB will beat Aurora on both cost and operational simplicity. Don't read this article as a recommendation to default to relational.

For an ad-ops monitoring product that needs multi-entity joins, time-series windowing, evolving query shapes, and idempotent bulk-write semantics from a cron job — Aurora Serverless v2 + Drizzle + postgres-js on Vercel Fluid Compute is the most productive stack I've built in years.

What's next

The reusable engineering lesson from this project isn't actually the database choice — it's how Claude's structured output via the AI SDK's Output.object({ schema }) lets the AI return data the rest of your system already knows how to use. I'll write that up next.

Try it live:

• Dashboard demo: runadengine.com/dashboard
• 2-min walkthrough: youtu.be/poFYDHB9WyU
• Pilot signup: runadengine.com/signup

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