Your team picked DynamoDB because it scales. But now someone's written a Scan that costs more than the feature it supports, a new feature needs a query your table can't do without a redesign, and nobody's quite sure how GSI projections work.
I built FluentDynamoDB to solve these problems in .NET: type-safe queries, compile-time validation, a repository pattern that makes DynamoDB feel like it should have from the start. But the library only gets you so far. Getting the data model right is the harder half, and that's where I see teams burn weeks going in circles.
What I typically see
- → Scans where Queries should be
- → GSIs created "just in case" that cost real money every month
- → Single-table design adopted but nobody remembers why the keys look like that
- → Raw SDK boilerplate copy-pasted across 30 files
What it looks like after
- → Every access pattern maps to a Query on a known index
- → GSIs designed from actual access patterns
- → Schema documented well enough that new devs can add entities without a meeting
- → Type-safe repositories that catch key schema mistakes at compile time
- → Capacity mode and projections tuned for your actual workload
Why work with the library's author?
When you hit an edge case, I can tell you immediately whether it's a DynamoDB limitation, a library limitation, or a data model problem. No guessing, no Stack Overflow rabbit holes.
I can also extend the library for your use case. Need a custom source generator for your tenant isolation pattern? A transaction wrapper that fits your domain? That's on the table in a way it isn't with anyone else.
Sound familiar?
"We're starting a new service and our whole team has a relational background."
I'll work through your access patterns with you, design the schema, set up FluentDynamoDB, and make sure your team understands the why behind each decision — not just the what.
"Our DynamoDB costs are growing faster than our traffic."
Usually expensive Scans, over-projected GSIs, or wrong capacity mode. I'll find the specific access patterns that are killing you and fix the schema to make them cheap.
"Someone sold us on single-table design and now it's a mess."
Single-table isn't always right, and it's easy to get wrong. I'll help you figure out what should stay, what should split, and how to get there without a big-bang migration.
"We want to adopt FluentDynamoDB but we have 50 existing entities."
You don't have to migrate everything at once. I'll help you set up the patterns and migrate one entity as a reference, then your team can follow the pattern for the rest.
How an engagement typically works
We map your access patterns
What queries does your application actually need? What's the read/write ratio? What's the cardinality? This drives everything else.
I design (or fix) the schema
Key design, GSI strategy, single-table vs multi-table decision, and capacity mode. You get a document explaining the rationale.
Implementation with FluentDynamoDB
Entity mappings, repository setup, and the patterns your team will follow going forward. Working code, not just diagrams.
Knowledge transfer
Your team understands the schema, the patterns, and how to add new entities on their own. I'm not trying to create dependency.
Frequently Asked Questions
What is FluentDynamoDB?
FluentDynamoDB is an open-source .NET library that provides a type-safe, fluent API for working with Amazon DynamoDB. It includes a source-generated repository pattern, compile-time query validation, and built-in support for single-table design patterns. It eliminates the boilerplate of the AWS SDK while keeping you close to DynamoDB's actual capabilities.
Do I need to use single-table design with FluentDynamoDB?
No. FluentDynamoDB supports both single-table and multi-table approaches. Single-table design can reduce costs and simplify access patterns for certain workloads, but it's not always the right choice. I can help you evaluate whether single-table makes sense for your specific access patterns and team.
Can FluentDynamoDB work with an existing DynamoDB table?
Yes. FluentDynamoDB doesn't require any specific table structure. You define your entity mappings to match your existing schema, and the library generates the repository code accordingly. Migration from raw SDK calls or other libraries is incremental — you can adopt it one entity at a time.
How does FluentDynamoDB handle DynamoDB's limitations?
FluentDynamoDB embraces DynamoDB's model rather than hiding it. Query and Scan operations are explicit, GSI access is type-safe, and transaction boundaries are clear. The compile-time validation catches common mistakes like querying a GSI with the wrong key schema before you deploy. It makes DynamoDB's constraints visible and manageable rather than surprising.