PostgreSQL, MongoDB, DynamoDB. I pick the database that fits your actual data and traffic, not just whatever's trendy.
Picking the wrong database up front, a relational database for data that's actually document-shaped, or the reverse, is one of the most expensive mistakes to fix after launch. Once real data and real users are already in the system, moving it to a different database means careful migration work instead of a quick config change. I scope this decision before writing any code, based on how your data actually relates to itself, not on which database happens to be popular this year. Getting it right the first time is far cheaper than fixing it after the fact.
I've shipped production systems on PostgreSQL, using Drizzle ORM and NeonDB, on MongoDB, and on DynamoDB, so a recommendation for your project comes from having actually run each of them in production, not from reading a comparison article. That matters because each database has real tradeoffs that only show up under actual usage, like how each one handles concurrent writes or complex relational queries at scale. Having built with all three means I can point out the tradeoff that actually matters for your specific case instead of repeating generic advice.
On a client project, DynamoDB and MongoDB backend work supported a system that needed to keep scaling without a full rewrite along the way. That's the practical goal with any database choice: not just handling today's traffic, but handling ten times today's traffic without requiring you to start over. A database chosen and structured well from the start absorbs that growth gradually. One chosen poorly tends to hit a wall that forces an expensive, disruptive migration exactly when your business can least afford the downtime.
If you already have data in a database and need to move or restructure it, I plan the migration path carefully before touching anything in production. That usually means a rollback plan, a staging environment to test against first, and a clear sequence of steps rather than a single risky cutover. Data loss or unexpected downtime during a migration can be a genuinely serious problem for a live business, so this isn't a step I rush regardless of how simple it might look on paper. Careful planning up front is what keeps a migration boring instead of a crisis.
I'll explain why a particular database fits your project in plain terms you can actually evaluate, not just default to whatever I personally happen to know best. If PostgreSQL is the better fit because your data has clear relationships between users, orders, and products, I'll explain it that way rather than hiding behind technical vocabulary. That matters because you're the one who has to live with the decision long after I've moved on to the next project, so you deserve to actually understand why it was made.
How do I know if I need PostgreSQL or MongoDB?
Roughly, if your data is naturally structured with clear relationships, users, orders, products, PostgreSQL usually fits better. If it's more flexible or document-like, content, logs, varying shapes, MongoDB often fits better. I'll look at your actual case rather than default to one.
Database work spans PostgreSQL (Drizzle ORM, NeonDB), MongoDB, and DynamoDB, including backend systems for PennyCanny (DynamoDB/MongoDB) and a property management system backend (PostgreSQL via Drizzle).
Case Study
PennyCanny
Backend systems built on DynamoDB and MongoDB, supporting multiple client engagements.
Case Study
Property management system (backend)
Backend built with NestJS, Drizzle ORM, and PostgreSQL.
Do you work with PostgreSQL specifically?
Yes, regularly, including with Drizzle ORM and NeonDB.
Do you work with MongoDB specifically?
Yes, used in production client backend work.
What if I have a limited budget for database work?
Tell me what you're working with on a quick call and I'll be upfront about what's realistic for the budget.
How do you handle migrating an existing database?
Carefully. I plan the migration path before touching production data, usually with a rollback plan.
Do you work with DynamoDB specifically?
Yes, used in production backend systems handling real client traffic.
Do you only work with clients in certain countries?
No. I work with serious clients wherever they're based, remote, across time zones.
I ask questions until the requirement is actually clear. I don't start building against a guess. If something's ambiguous, I'll flag it rather than assume.
Once we're aligned on what's being built and why, I start. No scope creep surprises later because we didn't nail this down first.
You get regular progress updates, even small ones. You shouldn't have to ask where things stand. Core, high-stakes pieces get built carefully, and lower-stakes pieces move fast so we can iterate on real feedback.
Ship it, and walk you through anything you need to run or extend it yourself.
Landing page
From $800
MVP
From $4,000
SaaS product
From $8,000
Ongoing work
$40 to $70/hr
These are starting points, not fixed quotes. Book a free scoping call, no obligation, and I'll give you a real number based on what you actually need. Or drop me an email at [email protected] if that's easier.
Book a free scoping call