Proposed flow for this scenario
- List application requests
- Identify keys and relationships
- Choose consistency boundary
- Model contention and failure
- Test recovery and cost
This flow describes a design to evaluate. The local experiment explores one stated mechanism. Its scope appears with the controls; the proposed services are not provisioned.
Decision checkpoints
| Choice | Fits when | Watch for |
|---|---|---|
| DynamoDB | Known key lookups and intentional access-pattern modeling fit the workload. | Expecting an arbitrary relational JOIN or using Scan for every interactive request. |
| RDS | Relational constraints, engine-specific SQL and evolving joined queries are central. | Ignoring connections, migration, storage and availability requirements. |
| Separate reporting path | Broad analysis has different freshness and access needs. | Duplicating authoritative data without synchronization and ownership rules. |
Write the operation before the schema
LetX reads one export by workspace and request ID. QuantumSketch combines projects, collaborators and outcomes for changing reports. List each request’s identifiers, ordering, result size and correctness requirement. Those differences provide evidence for a database choice; the fact that both applications exchange JSON does not.
A DynamoDB key design should support the intended requests deliberately. An RDS engine brings relational operations, but the application still needs suitable indexes, transactions and query limits. A poorly designed query can be expensive on either system.
Do not confuse a filter with an access path
A DynamoDB Query uses its key conditions to select an access path; a filter is applied after items are evaluated. Adding a filter does not make every across-workspace report a direct lookup. A new request can require a new index, derived model or reporting design.
The local DynamoDB explorer supports a bounded base table, typed items and selected conditions, Query and Scan. It does not implement indexes or transactions. The local RDS console stores configuration but executes no SQL, so it cannot compare real query speed.
Decide which writes must succeed together
In real AWS, DynamoDB supports transactions as well as conditional item writes. RDS transaction behavior depends on the engine and operation. The useful question is which records and external effects share a consistency requirement, not whether one product is simply “transactional.”
Practice a conditional LetX job creation and repeat the same key. Inspect why the second attempt is rejected rather than overwriting the authoritative job. Then describe how a multi-record invariant would be implemented outside the currently supported local subset.
Original comparison worksheet
As an original design worksheet, list three LetX operations: create a job once, read its current result and list recent jobs for one workspace. Then add QuantumSketch’s cross-project report. Mark the identifiers available at each call and whether the caller needs an authoritative current value. These are deliberately different request shapes, not measurements.
Before introducing a reporting copy, write who owns it, how fresh it must be and what happens when its update fails. A secondary model can be useful but changes the recovery obligations. Database selection should account for that extra write and reconciliation work instead of presenting an additional store as a free query shortcut.
Recovery and the changed requirement
Question: a new support report needs every failed job across all workspaces. Can the original single-workspace Query satisfy it by adding a status filter? No. The partition boundary remains. Revisit the report’s access, freshness, authorization and write consequences before choosing an alternative.
Compare operational cost and recovery for the complete workload, including backups, availability, data movement and reporting copies. The retry experiment below models repeated attempts; it neither runs SQL nor benchmarks DynamoDB. No database choice is universally faster, cheaper or best for a small application.
Practice the supported console workflow
Predict it. Test it. Change one thing.
Local educational model. No account or cloud charges. Nothing is deployed to AWS.
Nested retries multiply attempts in the worst case. Backoff and jitter change timing; they do not reduce this configured upper bound. Real failures need an end-to-end retry budget.
sim.shahriarlabs.com · Free to explore
Sources and scope
Reviewed against these official references. The model’s supported scope appears alongside its controls.
How we review explanations