The Single-Table DynamoDB Reality Check

A structured analysis of single-table DynamoDB design across 12 months of production deployment: boundaries of applicability, documented failure modes, and a decision framework for practitioners.

Executive Summary

Single-table DynamoDB design delivers measurable operational benefits—zero cross-tenant data leaks, sub-100ms hierarchical query performance, and substantial repository boilerplate reduction—when applied within bounded domain contexts. However, organizations that extend single-table design across entire application surfaces encounter escalating cost and engineering overhead, particularly for analytics, flexible search, and time-series workloads. A production deployment encompassing 56 entity types and 23,820 lines of DynamoDB code over 12 months revealed four critical anti-patterns that collectively introduced an estimated $55,440 in first-year costs, including technical debt and ongoing operational waste. The appropriate architectural posture is one table per bounded context, not one table per application. AI-assisted codebase auditing identified all four anti-patterns at a fraction of the cost of manual review.

---

Key Findings

• Single-table design is context-scoped, not application-wide. Applying a single-table model across unbounded domains produces conflicting access patterns, GSI proliferation, and cross-domain compliance entanglement.
• Direct AWS SDK bypasses represent the highest-risk architectural violation. A production audit identified 217 direct SDK calls circumventing tenant isolation, PII encryption, audit logging, and retry logic—an estimated $24,000 remediation liability.
• DynamoDB is not cost-competitive for time-series workloads. Analytics data stored in DynamoDB cost $255 per month versus$45 per month for an equivalent purpose-built time-series service—a 5.6× cost differential.
• GSI proliferation signals access-pattern misalignment. Entities requiring more than three GSIs to serve query requirements are systematically better served by a search platform; the observed 12-GSI proliferation cost an estimated 120 engineering hours.
• AI-assisted auditing identifies architectural violations at scale. A 23,820-line codebase was scanned in 15 minutes, producing actionable violation reports with file-level and line-level specificity.
• Technical debt in distributed data access patterns compounds without automated governance. Without preventive controls, the observed SDK violation rate is consistent with exponential growth in subsequent development periods.

---

1. Introduction: Scope and Methodology

Single-table DynamoDB design, as formalized and popularized through AWS re:Invent presentations and practitioner literature, posits that all entities within an application can be stored in a single DynamoDB table through disciplined use of composite keys and Global Secondary Indexes (GSIs). The model offers well-documented advantages: reduced operational overhead, predictable latency at scale, and co-located entity hierarchies.

This analysis documents a 12-month production deployment of a multi-tenant SaaS platform using single-table DynamoDB, covering the full evolution from an initial single-table design to an architecture of 19 domain-aligned tables. The deployment comprised 56 entity types, 23,820 lines of DynamoDB-related code, and an AI-powered audit system that identified and quantified architectural violations across the codebase.

The analytical objective is to derive a replicable decision framework for practitioners evaluating single-table DynamoDB design, grounded in production evidence rather than idealized demonstrations.

---

2. Where Single-Table Design Delivers Value

2.1 Tenant Isolation via Partition Key Enforcement

The most consequential operational benefit of single-table DynamoDB for multi-tenant platforms is the enforcement of tenant data isolation at the database access layer, not the application logic layer. When the partition key schema uniformly encodes the tenant identifier—for example, TENANT#<tenant_id>—DynamoDB’s query semantics make cross-tenant access structurally impossible for well-formed queries.

The following repository pattern illustrates this isolation guarantee:

// platform-core/src/repository/tenant_repository.rs

// Every query is scoped to tenant
pub async fn find_lead(&self, tenant_id: &str, lead_id: &str) -> Result<Lead> {
    self.client
        .query()
        .table_name(&self.table_name)
        .key_condition_expression("PK = :pk AND SK = :sk")
        .expression_attribute_values(":pk", AttributeValue::S(format!("TENANT#{}", tenant_id)))
        .expression_attribute_values(":sk", AttributeValue::S(format!("LEAD#{}", lead_id)))
        .send()
        .await?
}

// Impossible to accidentally query across tenants
// No SQL injection, no WHERE clause bugs

This platform sustained zero cross-tenant data leak incidents over 12 months across 100 tenants—an outcome attributable primarily to partition key enforcement rather than application-layer guards.

2.2 Hierarchical Query Performance

Single-table design provides a structural advantage for hierarchical entity relationships. Sort key prefix patterns enable multi-level parent-child traversal in a single query, eliminating join operations that relational databases require and that DynamoDB does not support natively.

The following pattern demonstrates hierarchical traversal at sub-100ms latency:

// Fetch all accounts for a tenant's capsule
PK: TENANT#abc123
SK begins_with: CAPSULE#xyz#ACCOUNT#

// One query, no joins, <100ms
pub async fn list_accounts_for_capsule(
    &self, 
    tenant_id: &str, 
    capsule_id: &str
) -> Result<Vec<Account>> {
    self.client
        .query()
        .table_name(&self.table_name)
        .key_condition_expression("PK = :pk AND begins_with(SK, :sk_prefix)")
        .expression_attribute_values(
            ":pk", 
            AttributeValue::S(format!("TENANT#{}", tenant_id))
        )
        .expression_attribute_values(
            ":sk_prefix", 
            AttributeValue::S(format!("CAPSULE#{}#ACCOUNT#", capsule_id))
        )
        .send()
        .await?
}

Benchmark results at 10,000 accounts per tenant returned a 99th-percentile latency of 87ms. This performance characteristic is a direct function of DynamoDB sort key ordering, which enables efficient range scans without secondary indexes.

2.3 Macro-Driven Repository Automation

Single-table patterns exhibit high structural regularity within a bounded context, making them amenable to code generation through procedural macros. The platform implements a #[derive(DynamoRepository)] macro that generates the full repository layer from a declarative entity annotation:

// crm/src/domain/lead.rs

#[derive(DynamoRepository)]
#[dynamo(
    table = "crm-domain",
    pk = "TENANT#{tenant_id}",
    sk = "LEAD#{id}",
    gsi1 = "OWNER#{owner_id}",
    gsi2 = "CREATED#{created_at}"
)]
pub struct Lead {
    pub id: LeadId,
    pub tenant_id: String,
    pub owner_id: String,
    pub name: String,
    pub status: LeadStatus,
    pub created_at: DateTime<Utc>,
}

// Macro generates:
// - save(&self) -> Result<()>
// - find_by_id(tenant_id, lead_id) -> Result<Lead>
// - list_by_owner(tenant_id, owner_id) -> Result<Vec<Lead>>
// - list_by_created_date(tenant_id, start, end) -> Result<Vec<Lead>>
// - delete(tenant_id, lead_id) -> Result<()>

Across 56 entities, this approach eliminated an estimated 16,800 lines of repository boilerplate (300 lines per entity × 56 entities). For implementation details, see The Macro That Wrote 80% of Our Repositories.

2.4 Geographic Data Residency

Tenant-aligned partition keys provide a natural routing anchor for multi-region data residency compliance. The following pattern routes writes to the appropriate regional DynamoDB table based on tenant configuration:

// platform-core/src/repository/multi_region_repository.rs

pub struct MultiRegionRepository {
    us_client: DynamoDbClient,
    eu_client: DynamoDbClient,
    tenant_cache: Arc<Moka<String, DataRegion>>,
}

impl MultiRegionRepository {
    pub async fn save_lead(&self, lead: &Lead) -> Result<()> {
        let region = self.get_tenant_region(&lead.tenant_id).await?;
        
        let client = match region {
            DataRegion::US => &self.us_client,
            DataRegion::EU => &self.eu_client,
        };
        
        client.put_item()
            .table_name(format!("crm-domain-{}", region.table_suffix()))
            .item("PK", AttributeValue::S(format!("TENANT#{}", lead.tenant_id)))
            .item("SK", AttributeValue::S(format!("LEAD#{}", lead.id)))
            // ... other attributes
            .send()
            .await?;
        
        Ok(())
    }
}

This design enforces regional data boundaries at the infrastructure layer, satisfying GDPR Article 44 cross-border transfer restrictions by construction rather than policy enforcement.

---

3. Anti-Patterns and Their Costs

3.1 Anti-Pattern: Direct AWS SDK Bypass

An AI audit of the production codebase identified 217 instances of direct aws-sdk-dynamodb calls that bypassed the repository abstraction layer. Each such instance eliminated the protections that the repository layer enforces: tenant isolation validation, PII field encryption, audit event emission, and exponential backoff retry logic.

The following example illustrates the class of violation:

// integration/src/sync/salesforce_sync.rs:342
// ❌ WRONG: Direct SDK call bypassing safety mechanisms

use aws_sdk_dynamodb::Client;

async fn sync_lead_from_salesforce(&self, lead_data: SalesforceResponse) -> Result<()> {
    // Direct SDK call - bypasses tenant isolation!
    self.dynamo_client
        .put_item()
        .table_name("crm-domain")
        .item("PK", AttributeValue::S(format!("TENANT#{}", self.tenant_id)))
        .item("SK", AttributeValue::S(format!("LEAD#{}", lead_data.id)))
        .item("name", AttributeValue::S(lead_data.name))
        .item("email", AttributeValue::S(lead_data.email))  // ❌ PII not encrypted!
        .send()
        .await?;
    
    Ok(())
}

The compliant pattern routes through the repository abstraction:

// ✅ CORRECT: Use repository layer

async fn sync_lead_from_salesforce(&self, lead_data: SalesforceResponse) -> Result<()> {
    let lead = Lead {
        id: LeadId::new(),
        tenant_id: self.tenant_id.clone(),
        name: lead_data.name,
        email: lead_data.email,  // ✅ Repository encrypts PII automatically
        // ...
    };
    
    // Repository handles:
    // - Tenant isolation (validated)
    // - PII encryption (automatic)
    // - Audit logging (event sourced)
    // - Retries (exponential backoff)
    self.lead_repository.save(&lead).await?;
    
    Ok(())
}

At 20–30 minutes of remediation per violation, the 217 identified instances represent 80–120 hours of engineering time—an estimated $16,000–$24,000 at a fully-loaded rate of $200 per hour.

Direct AWS SDK calls that bypass the repository layer are not merely a code quality issue—they represent a security boundary violation. Each such call is a potential cross-tenant data leak, a GDPR compliance gap, and an audit trail omission. Remediation cost scales linearly with the number of violations. Preventive controls (pre-commit hooks, linting rules) are orders of magnitude cheaper than retroactive remediation.

3.2 Anti-Pattern: Scan Operations in List Queries

Seven repositories were identified using scan() operations instead of query() for standard list operations. DynamoDB scan() reads every item in the table before applying filter expressions; filter evaluation occurs after reads, providing no cost savings.

The following example demonstrates the problematic pattern and its resolution:

// catalog/src/repository/product_repository.rs:156
// ❌ WRONG: Scanning entire table

pub async fn list_products_by_category(
    &self, 
    tenant_id: &str, 
    category_id: &str
) -> Result<Vec<Product>> {
    let result = self.client
        .scan()  // ❌ Reads EVERY item in table
        .table_name(&self.table_name)
        .filter_expression("tenant_id = :tenant AND category_id = :category")
        .expression_attribute_values(":tenant", AttributeValue::S(tenant_id.to_string()))
        .expression_attribute_values(":category", AttributeValue::S(category_id.to_string()))
        .send()
        .await?;
    
    // Scan reads 100,000 items, filters to 50 matches
    // Cost: 100,000 RCU
    Ok(parse_items(result.items))
}

The corrected pattern uses a GSI to scope reads to the matching partition:

// ✅ CORRECT: Query with GSI

#[derive(DynamoRepository)]
#[dynamo(
    table = "catalog-domain",
    pk = "TENANT#{tenant_id}",
    sk = "PRODUCT#{id}",
    gsi1_pk = "TENANT#{tenant_id}#CATEGORY#{category_id}",  // ✅ Add GSI
    gsi1_sk = "PRODUCT#{id}"
)]
pub struct Product { /* ... */ }

pub async fn list_products_by_category(
    &self, 
    tenant_id: &str, 
    category_id: &str
) -> Result<Vec<Product>> {
    let result = self.client
        .query()  // ✅ Reads only matching items
        .table_name(&self.table_name)
        .index_name("GSI1")
        .key_condition_expression("GSI1PK = :pk")
        .expression_attribute_values(
            ":pk", 
            AttributeValue::S(format!("TENANT#{}#CATEGORY#{}", tenant_id, category_id))
        )
        .send()
        .await?;
    
    // Query reads 50 items directly
    // Cost: 50 RCU (2000x improvement)
    Ok(parse_items(result.items))
}

Monthly cost impact before remediation: 500 million RCU at approximately $500/month. After remediation across seven repositories: approximately$0.25/month—a reduction of $210/month.

3.3 Anti-Pattern: Excessive GSI Proliferation

When entities require more than two or three GSIs to serve their access patterns, the cumulative cost of single-table design typically exceeds that of a purpose-built search service. The product catalog entity in this deployment required four GSIs:

// catalog/src/domain/product.rs

#[derive(DynamoRepository)]
#[dynamo(
    table = "catalog-domain",
    pk = "TENANT#{tenant_id}",
    sk = "PRODUCT#{id}",
    
    // GSI1: Query by category
    gsi1_pk = "TENANT#{tenant_id}#CATEGORY#{category_id}",
    gsi1_sk = "PRODUCT#{id}",
    
    // GSI2: Query by brand
    gsi2_pk = "TENANT#{tenant_id}#BRAND#{brand_id}",
    gsi2_sk = "PRODUCT#{id}",
    
    // GSI3: Query by price range
    gsi3_pk = "TENANT#{tenant_id}#PRICETIER#{price_tier}",
    gsi3_sk = "PRICE#{price}",
    
    // GSI4: Query by SKU
    gsi4_pk = "TENANT#{tenant_id}#SKU#{sku}",
    gsi4_sk = "PRODUCT#{id}"
)]
pub struct Product {
    pub id: ProductId,
    pub tenant_id: String,
    pub category_id: String,
    pub brand_id: String,
    pub sku: String,
    pub price: Decimal,
    pub price_tier: PriceTier,  // Computed: LOW, MEDIUM, HIGH
}

Each GSI replicates the full item set, multiplying storage costs. The cross-entity cumulative count reached 12 GSIs (representing 8–12 engineering hours each), yielding an estimated 120 hours of avoidable development investment. An OpenSearch instance at $45/month with a one-time 20-hour integration effort would have provided superior query flexibility at lower total cost.

The alternative using OpenSearch for flexible filtering:

// catalog/src/repository/product_search_repository.rs

// ✅ Use OpenSearch for flexible queries

pub async fn search_products(&self, query: ProductQuery) -> Result<Vec<Product>> {
    let mut search = SearchQuery::new();
    
    // Tenant isolation (mandatory)
    search.filter("tenant_id", query.tenant_id);
    
    // Flexible filters (no GSI needed)
    if let Some(category) = query.category {
        search.filter("category_id", category);
    }
    if let Some(brand) = query.brand {
        search.filter("brand_id", brand);
    }
    if let Some((min, max)) = query.price_range {
        search.range("price", min, max);
    }
    if let Some(sku) = query.sku {
        search.match_field("sku", sku);
    }
    
    self.opensearch_client.search(search).await
}

3.4 Anti-Pattern: Time-Series Data in DynamoDB

DynamoDB pricing is based on provisioned or consumed read/write capacity units, with costs scaling linearly with data volume. Purpose-built time-series databases optimize for compression, downsampling, and aggregation—capabilities that DynamoDB does not provide natively, requiring expensive application-layer computation.

The original metrics repository:

// analytics/src/repository/metrics_repository.rs

#[derive(DynamoRepository)]
#[dynamo(
    table = "analytics-domain",
    pk = "TENANT#{tenant_id}#METRIC#{metric_name}",
    sk = "TIMESTAMP#{timestamp}",
    ttl = "expiration_time"  // Auto-delete after 90 days
)]
pub struct MetricDataPoint {
    pub tenant_id: String,
    pub metric_name: String,
    pub timestamp: DateTime<Utc>,
    pub value: f64,
    pub dimensions: HashMap<String, String>,
    pub expiration_time: u64,  // TTL for automatic deletion
}

// Query: Get hourly aggregates for last 30 days
pub async fn get_hourly_metrics(
    &self,
    tenant_id: &str,
    metric_name: &str,
    start: DateTime<Utc>,
    end: DateTime<Utc>
) -> Result<Vec<AggregatedMetric>> {
    // 1. Query raw data points (30 days × 24 hours × 60 minutes = 43,200 points)
    let raw_points = self.client
        .query()
        .table_name(&self.table_name)
        .key_condition_expression("PK = :pk AND SK BETWEEN :start AND :end")
        .expression_attribute_values(
            ":pk",
            AttributeValue::S(format!("TENANT#{}#METRIC#{}", tenant_id, metric_name))
        )
        .send()
        .await?;
    
    // 2. Aggregate in Lambda (expensive compute)
    let aggregated = self.aggregate_by_hour(raw_points)?;
    
    Ok(aggregated)
}

The Timestream-based replacement eliminates application-layer aggregation:

// analytics/src/repository/timestream_metrics_repository.rs

pub struct TimestreamMetricsRepository {
    client: TimestreamQueryClient,
    database: String,
    table: String,
}

impl TimestreamMetricsRepository {
    pub async fn get_hourly_metrics(
        &self,
        tenant_id: &str,
        metric_name: &str,
        start: DateTime<Utc>,
        end: DateTime<Utc>
    ) -> Result<Vec<AggregatedMetric>> {
        let query = format!(
            "SELECT 
                bin(time, 1h) as hour,
                avg(measure_value::double) as avg_value,
                max(measure_value::double) as max_value,
                min(measure_value::double) as min_value
            FROM \"{}\".\"{}\"
            WHERE tenant_id = '{}'
              AND measure_name = '{}'
              AND time BETWEEN '{}' AND '{}'
            GROUP BY bin(time, 1h)
            ORDER BY hour",
            self.database, self.table, tenant_id, metric_name,
            start.to_rfc3339(), end.to_rfc3339()
        );
        
        // Timestream does aggregation natively (no Lambda needed)
        let result = self.client.query().query_string(query).send().await?;
        
        Ok(parse_timestream_result(result))
    }
}

Monthly cost at equivalent workload: $255 for DynamoDB (storage + RCU + Lambda compute) versus$45 for Timestream—a 5.6× differential, representing $210/month in avoidable cost.

---

4. Comparative Analysis: Database Selection by Workload

The following table summarizes workload characteristics and the recommended persistence mechanism based on observed production outcomes.

Workload Type	Recommended Service	Rationale	DynamoDB Suitability
Transactional CRUD within bounded context	DynamoDB (single-table)	Tenant isolation, hierarchical queries, predictable latency	High
Hierarchical parent-child traversal	DynamoDB (single-table)	Sort key prefix enables no-join traversal	High
Full-text and flexible attribute search	OpenSearch	No GSI proliferation, flexible query composition	Low
Time-series with aggregation	AWS Timestream	Native compression, downsampling, SQL aggregation	Low
Cross-domain analytics joins	Redshift / Snowflake	Columnar storage, SQL joins across domains	Not applicable
Session/ephemeral data	DynamoDB (TTL)	Built-in TTL, low operational overhead	High
Audit logs (long-retention)	S3 + Athena	Cost-efficient cold storage, SQL query access	Moderate

The recommended database selection principle is: use DynamoDB for transactional workloads with known, bounded access patterns; delegate analytics, search, and time-series workloads to purpose-built services. Cost modelling should be performed before committing to DynamoDB for any workload that requires aggregation, flexible filtering, or cross-entity joins.

---

5. Cost Summary

The following table quantifies the total first-year cost attributable to the four anti-patterns identified in this analysis.

Anti-Pattern	One-Time Remediation Cost	Monthly Recurring Waste	Annual Total
217 direct SDK bypasses	$24,000 (120 hours @$200/hr)	—	$24,000
7 scan operations	—	$210/month	$2,520
12 GSI over-provision	$20,000 opportunity cost	—	$20,000
Time-series in DynamoDB	—	$210/month	$2,520
Total	$44,000	$420/month	$49,040

The figures above represent the cost of anti-patterns that were introduced progressively over a 12-month development period. The majority of these violations were introduced by development agents operating without explicit architectural constraints. Retroactive remediation is significantly more expensive than preventive governance. Practitioners should implement pre-commit hooks, linting rules, and architectural fitness functions prior to reaching scale.

---

6. AI-Assisted Architectural Auditing

Manual review of a 23,820-line codebase for architectural violations is estimated at 120 senior-engineer-hours. An AI-assisted audit completed the equivalent analysis in approximately 15 minutes, producing findings with file-level and line-level specificity. The audit identified all 217 SDK violations, all seven scan operations, and all 12 GSI over-provisions with zero false negative architectural categories.

AI auditing excels at pattern-matching violations against established rules across large codebases. Human judgment remains essential for validating findings, adjudicating edge cases, and making architectural trade-off decisions (for example, whether a specific GSI is justified given access frequency).

Integrate AI-assisted codebase auditing into quarterly architecture review cycles. Define a machine-readable ruleset specifying prohibited patterns (direct SDK calls, scan operations in production list methods, GSI counts exceeding threshold), and run automated scans against pull request merges. This shifts cost from remediation to prevention.

---

7. Decision Framework: When to Apply Single-Table Design

7.1 Indicators for Single-Table DynamoDB

Organizations should apply single-table DynamoDB when the following conditions hold:

1. Entities share a domain boundary. The target entities participate in the same bounded context (for example, CRM entities: Lead, Account, Opportunity, Contact).
2. Hierarchical access patterns dominate. The primary query model involves traversal of parent-child relationships within a tenant scope.
3. Access patterns are known and stable. The required GSI set can be fully specified at design time and is not expected to grow beyond two to three indexes.
4. Tenant isolation is a first-order requirement. The partition key schema enforces isolation by construction, eliminating reliance on application-layer guards.

7.2 Indicators Against Single-Table DynamoDB

Organizations should select an alternative persistence mechanism when any of the following conditions hold:

1. Cross-domain queries are required. DynamoDB does not support joins; cross-domain analytics require a data warehouse or OLAP database.
2. Access patterns are unpredictable or evolving. Each new access pattern requires a new GSI; storage costs multiply as GSI count grows.
3. Time-series aggregation is a primary workload. Purpose-built services provide native compression and aggregation at substantially lower cost.
4. Different entities require different retention policies. Audit logs requiring seven-year retention should not co-exist in the same table as session data with 24-hour TTL.

The governing principle is: one table per bounded context, not one table per application.

---

8. Recommendations

1. Define and enforce a repository abstraction layer before writing any DynamoDB access code. Pre-commit hooks should reject any direct aws-sdk-dynamodb calls outside the designated repository module. Enforcement prior to development eliminates the remediation liability documented in Section 3.1.

2. Establish a GSI count threshold as an architectural fitness function. Entities requiring more than three GSIs should be evaluated for migration to OpenSearch before implementation proceeds. This threshold should be integrated into code review checklists and automated linting rules.

3. Conduct a workload classification exercise before selecting DynamoDB. For each planned entity type, explicitly classify the workload as transactional, time-series, full-text search, or analytical. Only transactional workloads with known access patterns should be assigned to DynamoDB.

4. Implement AI-assisted quarterly architectural audits. Define a machine-readable violation ruleset and run automated scans against the production codebase. The cost differential between proactive auditing and reactive remediation is approximately 10:1 based on the evidence in this analysis.

5. Use multi-region data residency routing at the repository layer. Geographic data residency for regulatory compliance is most reliably achieved by routing writes through region-aware repository constructors rather than application-layer conditional logic.

6. Migrate time-series workloads to purpose-built services at project inception. The 5.6× monthly cost differential identified in Section 3.4 is compounded by the application-layer aggregation overhead that DynamoDB necessitates. Early migration avoids both the cost differential and the engineering debt of custom aggregation logic.

---

9. Conclusion

The single-table DynamoDB model is a well-validated architectural pattern for transactional, tenant-isolated, hierarchically structured data within bounded domain contexts. Its application to entire application surfaces—spanning analytics, flexible search, and time-series workloads—introduces avoidable costs and operational complexity. Production evidence from a 12-month deployment establishes that the appropriate unit of single-table design is the bounded context, not the application.

The four anti-patterns identified in this analysis—SDK layer bypass, scan-based list operations, GSI proliferation, and time-series data in DynamoDB—are systematic rather than incidental. They are predictable outcomes of applying single-table design beyond its zone of competence and of developing without enforced architectural constraints. Organizations that instrument preventive governance mechanisms before scaling will avoid the remediation liabilities documented here.

As AI-assisted development tooling matures, the capacity for continuous architectural auditing at the codebase level will increasingly serve as a cost-effective substitute for periodic manual review. The combination of AI-driven violation detection and human architectural judgment represents a governance model well-suited to the pace and scale of modern software delivery.

---

Resources

• AWS re:Invent: Advanced DynamoDB Design Patterns (Rick Houlihan)
• DynamoDB Best Practices
• The DynamoDB Book by Alex DeBrie
• Why We Moved From DynamoDB to Timestream (Corey Quinn)
• The Macro That Wrote 80% of Our Repositories (this blog)

---

Further reading: The Macro That Wrote 80% of Our Repositories — How Rust macros automated the repository layer boilerplate that single-table design demands.

---

All content represents personal learning from personal projects. Code examples are sanitized and generalized. No proprietary information is shared. Opinions are my own and do not reflect my employer’s views.