I finished the Groundswell hackathon build with a working product, a deployed URL, and a list of things I wish I had known before I started. This is that list. Not the polished version where everything went according to plan — the actual version, including the three hours I spent debugging a database connection that was failing for a reason I had completely wrong.
Groundswell is a global daily opinion platform where players vote on a question and then predict how different countries and age groups voted. Your score comes from prediction accuracy, not opinion alignment. Building it in 72 hours using Next.js, Aurora DSQL, DynamoDB, and Amazon Bedrock taught me more about AWS database architecture than I expected. Most of what I learned came from mistakes.
Mistake 1 — Assuming Aurora DSQL Works Like Regular PostgreSQL
My mental model going in was that Aurora DSQL was PostgreSQL with a fancier name and better global distribution. It is not. It has a PostgreSQL-compatible connection interface, which means your queries look the same, but several things work differently and some features that standard PostgreSQL has are missing entirely.
The first problem was authentication. Aurora DSQL does not accept a static database password. Connection requires a short-lived token generated from your AWS credentials each time you connect. When running locally, this token comes from the Vercel CLI when you run the app with vercel dev. If you run the standard npm run dev command instead, the token is never injected, and every database connection attempt returns an access denied error. I spent several hours convinced my environment variables were wrong before realizing the issue was which command I used to start the server.
