DynoTable @dynotable

Rereading this in 2026 and it holds up, but worth being precise about why it failed, because it’s the opposite of the usual “Dynamo doesn’t scale” complaint. Dynamo scaled fine. The problem was the workload: web analytics is arbitrary, ad-hoc querying over event data, the one thing Dynamo is designed not to do. The Rockset detour proves it, you bolted a query engine on top because Dynamo alone couldn’t answer the questions, so you were paying for two systems to fake what one analytics engine does natively. SingleStore winning wasn’t Dynamo losing at its own game, it was finally matching the tool to a query-flexibility problem. The cost blowup is downstream of the same thing. Dynamo pricing punishes exactly what analytics generates: high-cardinality reads, scans, GSIs fanning out on every write. So the lesson is “don’t use a key-value store for analytics,” not “Dynamo is a trap.” Where I’d push back is how the post gets cited, as blanket “we ditched Dynamo, so should you.” For known, key-based patterns Dynamo still wins on ops and scale. The failure mode is reaching for it before you know your patterns, or when they’re inherently ad-hoc. Analytics is the second case, and you diagnosed it right. The subtler trap: a lot of teams think they need to leave Dynamo when they just modeled it wrong. Bad single-table design looks like “Dynamo can’t do this” when it’s really “I built the wrong keys.” That gap is what we work on at DynoTable, access-pattern-first modeling in the learn platform: dynotable.com/learn Great post either way, the honesty about reversing a public bet is rarer than the technical content.

You never encrypt secrets with one master key. Use envelope encryption, and almost every requirement hangs off that. Encryption at rest. Each secret gets its own data encryption key (DEK). Encrypt the secret with the DEK, then encrypt the DEK with a master key that lives in an HSM/KMS and never leaves. Store the encrypted secret next to its encrypted DEK. On read, KMS decrypts the small DEK, the DEK decrypts the secret. Master-key rotation only re-encrypts DEKs, not every secret, and a full DB compromise yields only ciphertext. Storage. Small, key-based, immutable versions, a clean key-value fit. PK secretId + version, never overwrite, append new versions so rotation and rollback come free. Store the blob, encrypted DEK, staging labels (current/previous), metadata. This is exactly the kind of versioned single-table modeling DynoTable’s learn platform walks through, worth a look if the DynamoDB side is new: dynotable.com/learn Rotation. A state machine, not a swap: create new version → stage as pending → test against the target → promote to current, demote old to previous. The old version stays valid through the transition so in-flight clients never break. Trigger per-secret via a scheduler. Access control. Policy-based, per-secret, per-action (read vs rotate vs admin). Authorize before the DEK is ever decrypted, so a denied request never touches KMS. Auditing. Every access emits an immutable event (who, what, when, allowed/denied) to an append-only WORM sink that lives outside the service’s write path, so compromising the service can’t rewrite history. Read path. Authz → cache check (short TTL) → on miss, fetch blob + DEK → KMS decrypts DEK → decrypt, cache briefly, audit, return. What interviewers actually probe: why envelope encryption (tiny master-key work, per-secret blast radius, cheap rotation), the dual-validity window during rotation, and tamper-proof out-of-band auditing. “Millions of reads/day” is low average QPS, the hard parts are the crypto model, rotation correctness, and audit integrity. Saying that out loud shows you can tell scale theater from real difficulty.

@neerajjj6785 Definitely AWS

Where it stops being true is scale and recall. pgvector via HNSW is solid, but once you’re into hundreds of millions of vectors, high QPS, or you need aggressive quantization and tuning to hold recall at low latency, the purpose-built stores (Qdrant, Milvus, etc.) start earning their keep. That’s a real threshold, just one most teams never reach. The trap on both sides is the same: dedicated vector DBs get reached for as a default because the category is hot, and then you’re running a second datastore, keeping it in sync with your source of truth, and doing metadata filtering across a network hop. That sync-and-filter tax is exactly what pgvector avoids by keeping vectors next to the data they belong to. So the honest rule: start with pgvector, and only move when you have a measured recall-or-latency problem at scale, not because the timeline says vector DBs are the thing. Same “do I actually have a reason to leave Postgres yet” question as always.

dynotable.com/learn/dynamodb…

A DynamoDB gotcha: sort keys sort as strings, so 10 comes before 2. If a sort key is numeric, zero-pad it to a fixed width (0002, 0010) so string order matches numeric order.

Love the native approach here. No Electron, sub-second cold start, 80MB idle, this is what a DB client should feel like. The breadth is impressive too. One thing I keep running into: DynamoDB is the odd one out in any multi-engine tool. It isn’t SQL underneath, so the general SQL-editor model only takes you so far, no real JOIN, no GROUP BY, and modeling lives or dies on access patterns, not tables. It’s the one engine where a specialized tool earns its keep. That’s why we built DynoTable: real SQL with joins and aggregations over Dynamo, plus an AI agent that runs on your own Bedrock keys, reads your actual schema, prefers Query over Scan, and stages every write as a diff you approve. Nothing leaves your AWS account. Connect Claude Code or Cursor over MCP too. dynotable.com

Solid cheat sheet. One correction worth flagging: DynamoDB defaults to eventually consistent reads, not strongly consistent. Strong reads cost 2x the RCUs and you opt into them. That one trips people up in interviews constantly. The thing a cheat sheet can’t teach is the part that actually bites in prod: access-pattern-first modeling. Get the keys wrong and no amount of GSIs saves you, you migrate. If anyone wants a level deeper than the summary, this curriculum covers modeling through internals, free, no signup: dynotable.com/learn

@dresscode_com @_syoryu89 version採番をRDB内で完結させ、ConditionExpressionはdrainer再実行時の冪等性に限定する、という切り分けが特に参考になりました。 Outbox導入後のDynamoDB側のキー設計や整合性モデルを整理する際には、DynoTable Learnも補助線として分かりやすいです。 dynotable.com/ja/learn

The economics are backwards. On-demand: writes are $1.25/M, eventually consistent reads are ~$0.125/M. Reads are the cheap side by ~10x. DynamoDB gets expensive when writes dominate, especially with GSIs where one write fans out to N. Also strong consistency is a per-request flag, same as Cassandra’s CL. And “paying for idle reads” hasn’t been a thing since on-demand shipped in 2018. Read-heavy is the workload DynamoDB is best at. Add DAX and it gets cheaper still. The real case for Cassandra is write-heavy at scale, or wanting to escape a metered bill entirely. What’s your read:write ratio?

@e_opore If you want to know more about DynamoDB check our learning section with free structured course with quizzes and interactive examples: dynotable.com/learn

dynotable.com/learn/dynamodb…

An item collection is every item sharing one partition key, the unit a single Query reads. It emerges from your key schema, you don't declare it. Design the sort key, design the Query.

Solid frame (“pay complexity in ops or in modeling”), but it cites ScyllaDB’s benchmark for DynamoDB’s worst failure mode. That’s like citing Oracle’s blog on Postgres. Also: adaptive capacity fixed hot partitions years ago. Hot keys are the thing that never gets fixed. Not mentioned once.

@CodeCrafters11 I’d argue with RDS, DynamoDB is pay as you go and really fast and scalable.

@amitkushh DynamoDB, but I’m biased 😁

@anah_sahh UI/UX - AI can’t actually see in a real sense, even looking at screenshot it can’t tell if UI is broken or not, and good UI is really hard even for humans

@CodeByNZ It is a skill, extracting reusable prompts into skills even more so

dynotable.com/learn/gsi-vs-l…

A GSI is a second copy of your table keyed differently, kept in sync for you. It answers queries the base key can't, for extra storage and write cost. Project only the attributes each pattern needs.