DEV Community: Martin Hicks

Dynoxide 1.3.0: security fixes and fussier pagination

Martin Hicks — Sat, 10 Oct 2026 23:32:04 +0000

Dynoxide 1.3.0 ended up a bit bigger than I'd planned. Working through the compatibility fixes turned up some DynamoDB behaviour I hadn't expected, and I also fixed two security issues that needed advisories.

There's a lot in the release notes, so I've picked out a few highlights below, including a contribution that makes test runs quieter and a few things to check before upgrading.

Two security fixes

One of these was in the code that explains why an expression is invalid. A request containing certain non-ASCII characters could make Dynoxide panic while building the syntax error's near: text. It cut the string in the middle of a UTF-8 character.

Release binaries abort on panic, so an emoji in a malformed expression could stop the server whilst it was trying to reject the request.

Expression parsing (rated High, 7.5): affected product versions are 0.9.10 through 1.2.1. An invalid character now gets a syntax error instead. Anyone who can reach the HTTP server could trigger the old behaviour without credentials, because it doesn't check request signatures. The default loopback binding limits that exposure, but a server on a shared network needs the upgrade. An in-memory database goes with the process; a file-backed database retains its last completed write. If you embed dynoxide-rs, the same call panics rather than aborting the process, unless you build with panic = "abort". Details in GHSA-gwhp-7jch-7xj6.
Tokens in help output (rated Low, 2.8): from 0.10.0 through 1.2.1, subcommand help printed the value of DYNOXIDE_MCP_AUTH_TOKEN if it was set. That's an unfortunate thing to put in a CI log or paste into a bug report. Help now names the variable without showing its value. If you've shared output containing the token, rotate it. Details in GHSA-3rv6-mrj3-vf9j.

Both are fixed in product 1.3.0 and Rust crate 3.0.0. The token fix also has a regression test checking which environment-backed flags are allowed to show their values.

There's a separate aws-smithy-json dependency update in the release notes. That dependency only reaches Dynoxide through the AWS SDK used by tests and benchmarks, and isn't shipped in the released artefacts.

The pagination rules are fussier than I'd expected

DynamoDB will give you a PartiQL pagination token, then refuse it if you add a space to the statement on the next request. Send the same list parameter again and it can refuse that too.

Dynoxide used to accept a pagination token when the statement parsed the same way. DynamoDB binds it to the text as sent, with some rather particular rules for parameters. 1.3.0 follows those rules:

Statement text must stay identical. Whitespace, keyword case and even the order of keys in a map literal matter. You can change Limit between pages.
Number parameters must match in value and scale. 1E2 and 1e+2 resume, as do 1.5E1 and 15, but 100 and 1E2 don't, and neither do 0 and 0.0.
Set order doesn't matter. Reordering the members still lets you resume.
List and map parameters don't resume at all. DynamoDB hands out a token on the first page, then rejects it even if you send the same parameter again. This was captured against both eu-west-2 and us-east-1.

If your application rebuilds or reformats its statement between pages, a local test should catch that. Previously Dynoxide let it through.

Requests that used to do the wrong thing

The fixes I care most about are the ones where a request succeeded and quietly did something else:

PartiQL comments or a table alias could lose the filter. A -- comment before WHERE could turn a SELECT into a read of every row, and so could a table alias such as FROM "T" t. Comments are now read as whitespace, and an alias is refused, as DynamoDB refuses it.
An unfilled ? could match items. flag <> ? with no parameters held for every item without flag, so a DELETE or UPDATE short of its parameters could delete or change them. A statement with more placeholders than parameters is now refused.
ORDER BY was accepted and ignored. Descending reads now actually descend, with DynamoDB's restrictions on which key combinations can be ordered.
Malformed legacy conditions could disappear. An invalid Expected condition could leave a write unguarded, and an invalid QueryFilter or ScanFilter could leave a read unfiltered. These requests are now refused.
A list write past the end padded the gap with NULLs. DynamoDB appends the value. SET tags[20] = :v on a two-element list now adds a third element.
A storage error could break transaction atomicity. SQLite can roll back a transaction itself on a full disk or an I/O error. Dynoxide used to carry on, allowing later actions to commit individually. Both transaction APIs now stop on the storage failure.

There's plenty of error-message work too, but these change what your application reads or writes.

More useful figures for tables and vectors

This release fixes how Dynoxide calculates vector write capacity, fills in missing table and index statistics, and makes capacity figures available through MCP:

Vector writes use four bytes per dimension. Previously Dynoxide sized the embedding as a list of numbers, which could add two or three write units for a 1,024-dimension vector. Reads and the 400 KB item limit still measure its numbers, as DynamoDB does.
Table and index sizes are populated. DescribeTable now reports table sizes and secondary-index counts and sizes that previously came back as zero. Dynoxide reports these live; AWS refreshes them roughly every six hours.
MCP tools can return consumed capacity. Ask for return_consumed_capacity: "INDEXES" to get the API's capacity breakdown through the tool response.

Global secondary indexes with multiple partition or sort key attributes also work properly now: sorting uses each sort key attribute in turn, queries require every partition key attribute, and items missing any key attribute stay out of the index. PartiQL still can't query these indexes, matching DynamoDB's restriction.

Quieter test runs, thanks to a contribution

Thanks to Anvilly Huang (@zhua633) for contributing --log quiet in #216. If your tests start and stop Dynoxide, it keeps the informational startup and shutdown messages out of their output:

dynoxide serve --log quiet

Warnings and errors still print. I've extended the option to MCP and import-and-serve too; the first-run MCP token message and the import report still appear.

Before upgrading

Keep a copy if you may roll back. Opening a persistent database upgrades it to schema version 11, and there's no way back. An older version only misreads the file if it has a multi-attribute GSI, whose entries are rebuilt, or a vector index, whose item sizes are recomputed. From 1.3.0, a file written by a newer Dynoxide is refused rather than opened. This applies to browser databases too.
Check Rust dependency versions. The product is 1.3.0, but dynoxide-rs is 3.0.0 because the Rust API has breaking changes. The parser modules are private and some PartiQL request and error structs have new fields. The crate still supports Rust 1.88; building its tests needs 1.94.1.
Check updates near the item-size limit. UpdateItem now measures the request's update charge alongside the finished item's size. Some previously refused updates succeed, and some previously accepted ones fail, matching the behaviour captured from DynamoDB.

The 1.3.0 release notes have the full list. For an npm project, npm install --save-dev dynoxide@1.3.0 pins this release.

Parity Suite 3.6 and a month of emulator fixes

Martin Hicks — Fri, 09 Oct 2026 15:19:10 +0000

When I wrote up 3.0.0 in August, Floci was a C on the board with 209 failing tests. By 3rd September the suite had grown to 1,251 tests and it was a D with 337. This morning's run has it failing one.

That's the real news in this release, and none of it is mine. The suite barely grew. The emulators got better.

The board

The suite reached 1,251 tests on 3rd September, so that's the fairest place to measure from. It's at 1,266 now.

	3rd September	9th October
Floci	D, 337 failing	A, 1 failing
LocalStack	B, 101 failing	A, 31 failing
MiniStack	C, 220 failing	B, 84 failing

All three now pass every Tier 1 test, the core of DynamoDB that most applications rely on. Five weeks ago Floci failed 50 of those, MiniStack 28 and LocalStack 14.

Floci didn't get there by doing less, either. Its coverage, the share of the suite it attempts rather than skips, went up from 95.1% to 99.4% over the same stretch.

Its one remaining failure is an edge case. A transaction carries a value nested deeper than DynamoDB's 32-level limit, but only in a condition, so it never gets written. Most regions don't check its depth and go on to evaluate the condition. eu-west-2 and the two other regions that now validate transactions up front (more on that below) refuse the whole request. Floci does neither: it cancels the transaction.

Most of LocalStack's 31 are PartiQL (21 of them), with the rest in exact error wording and limits. MiniStack's 84 are nearly all Tier 3, mostly exact error messages and limits.

It's good to see the board being used for what I built it for. Floci's tests and pull requests cite it by name, and MiniStack's maintainers point contributors to it when the question of how close to real DynamoDB they are comes up. Thanks to both teams for that.

AWS moved in the middle of a run

3.6.0 was tagged on 8th October and never published. While it was being measured, eu-west-2 changed how it validates transactions, so five tests failed against real DynamoDB and no board came out.

It's part of the same rollout I noticed back in June, and it still hasn't finished. eu-west-2, eu-north-1 and ap-northeast-2 now check a transaction's request before running it. The other 30 regions don't yet, and a few of the changes are more than wording: the same request can succeed in one region and fail in another.

For example, take an item that's already there, and a single SET that brings it up to exactly DynamoDB's 400KB limit (409,600 bytes), sent as an Update inside TransactWriteItems:

// bigValue brings the item to 409,600 bytes
await ddb.send(new TransactWriteItemsCommand({
  TransactItems: [{
    Update: {
      TableName: 'orders',
      Key: { pk: { S: 'Y' } },
      UpdateExpression: 'SET p = :p',
      ExpressionAttributeValues: { ':p': bigValue },
    },
  }],
}))

In us-east-1 that succeeds and the item is stored at 409,600 bytes. In eu-west-2, since 8th October, it fails with ValidationException: Item size to update has exceeded the maximum allowed size. If your tests run against one region and production sits in another, the two can disagree on this request. It's another reason you can't pin DynamoDB to one region.

3.6.1 is the fix. Those five tests accept either answer until the regions settle, and no engine loses a test over it. Pinning to the old answer would fail real DynamoDB in eu-west-2, which is the region the suite measures against, and pinning to the new one would fail every engine that matches the 30 regions still giving the old answer. Both answers are what DynamoDB actually does today, so both count.

Smaller changes

The board now sorts by grade, best first. It used to sort on divergence alone, which could put a target with a worse grade above a better one. No grade or figure changed.

The suite grew by fifteen tests across 3.5.0 and 3.6, fourteen of them from exoego, covering size and nesting limits on batch and transaction writes.

Coming next

The suite's going to grow again soon. I've found some gaps in what it covers, and there are around 160 new tests waiting to go in, all checked against real DynamoDB first. I'll probably merge them early next week, and I'd expect most engines' figures to move when they do.

The full notes are in the 3.6.1 release, the suite is at paritysuite/dynamodb-conformance, and the board is at paritysuite.org. If something looks wrong, an issue is welcome.

DynamoDB vector search without embeddings

Martin Hicks — Sun, 20 Sep 2026 19:08:25 +0000

Serverless Advocate #85 asks Lee Harding which AWS service he's most excited about, and he picks DynamoDB vector indexes. Not for embeddings, though. His point is that most people hear "vector" and think semantic search, when a vector index is "a general-purpose tool for any domain where you need to find 'nearest neighbours' in some n-dimensional space". Geometry, topology, geography, sensor fusion.

So I had a go at the geography case.

The setup is a store locator, which is about the most ordinary geography question going. Seven real places stand in for shops, five in and around Leeds and two over in York, each carrying its actual latitude and longitude. You stand somewhere and ask which ones are nearest.

A shop is about as plain as a DynamoDB item gets. Partition key, a name, two numbers:

{
  "PK":        { "S": "PLACE#p-101" },
  "name":      { "S": "Briggate" },
  "lat":       { "N": "53.79756" },
  "lon":       { "N": "-1.54169" },
  "openUntil": { "S": "18:00" }
}

No sort key, and the coordinates are ordinary numbers sat on the item. Nothing about that is searchable by distance yet, so the question is what you have to add to make it so.

Degrees aren't a space

You can't hand a vector index a latitude and longitude as two numbers, because degrees aren't a space. Cosine measures the angle your pair makes with the origin, and the origin here is just (0, 0). Nothing is measured from there, so two places on opposite sides of the world can score as basically identical. Euclidean is less daft and still wrong, because a degree of longitude is 111km at the equator and 66km up here in Leeds, so a circle in degree space is an ellipse on the ground. Neither is fixable by picking a different distance function. It's the space that's broken, not the metric.

What works is projecting onto the unit sphere, which is three lines of trig:

x = cos(lat) * cos(lon)
y = cos(lat) * sin(lon)
z = sin(lat)

That triple goes on the item as position, an ordinary list of numbers sitting beside the name and the opening hours, because there is no vector type in DynamoDB. A vector index over that attribute is what makes it searchable.

Now every shop is a point on a ball of radius one, and the straight-line gap between two of those points is 2 * sin(theta / 2), where theta is the angle between them at the centre of the ball. That climbs steadily from zero to pi and never doubles back, so ordering by it gives you the true great-circle ordering. Not an approximation of it. The score converts back to kilometres with 2 * 6371 * asin(score / 2), which across those seven shops agrees with haversine to about half a metre.

Next to a geohash

Worth running that next to the way proximity normally gets done in DynamoDB, which is a geohash. It interleaves the two coordinates into a single string, so nearby places end up sharing a leading prefix and "what's near me" becomes a prefix read. That's a lovely trick, and DynamoDB is very good at prefix reads.

Briggate's full hash is gcwfhct3. To make that queryable you take the first four characters as a cell, key a GSI on it, and keep the whole hash as the sort key so neighbours inside a cell order by position rather than by id:

{
  "PK":      { "S": "PLACE#p-101" },
  "name":    { "S": "Briggate" },
  "geohash": { "S": "gcwfhct3" },
  "GSI1PK":  { "S": "GEO#gcwf" },
  "GSI1SK":  { "S": "gcwfhct3#p-101" }
}

So "what's near me" becomes one Query on GSI1PK = GEO#gcwf, which is cheap and exact. It's also where the problem lives: the cell is the partition key. A shop in a neighbouring cell isn't ranked lower, it's in a different partition, and the query never goes near it.

I put the query point on the concourse at Leeds station, which sits in geohash cell gcwf, and asked both. Here are the five nearest shops of the seven, the York pair being a good 35km out and no trouble for either approach:

Shop	Distance	Cell	In the `gcwf` prefix read?
Briggate	0.45km	`gcwf`	yes
The Headrow	0.48km	`gcwf`	yes
Kirkgate Market	0.53km	`gcwf`	yes
Holbeck	0.92km	`gcwc`	no
Hyde Park	2.24km	`gcwf`	yes

Holbeck is a mile or so south of Leeds centre, and the cell boundary runs between it and the station. So the geohash hands you four shops, misses the one at 0.92km, and includes Hyde Park at two and a half times the distance because it happens to share four characters with where you're stood. That cell is roughly 23km by 19km, so this isn't a pathological case I've constructed: any query near an edge has it, which is most of them. Everyone who's built one of these knows about the boundary problem in the abstract. It's a bit sharper when the thing hands you a shop over twice as far away and looks perfectly happy about it.

Both access patterns are loaded in the console below, if you'd rather press it than take my word for it:

That's the engine running in your browser on the seven shops above. Run the vector search, then switch to the cell query, and Holbeck is the row that stops coming back.

Three lines of trig is still a model

So it's tempting to call this the version with no model in it. No weights to ship, and nothing to re-embed when a library version moves.

That's not quite right. Something decided degrees weren't the space and the unit sphere was, and that decision is now part of the index's contract in exactly the way an embedding model would be. Store vectors built one way, query with vectors built another, and nothing will tell you. Swap two components of the projection, or move to a different reference sphere, and you still hand over three finite numbers. The dimension count still matches, and the dimension count is the only thing a vector index ever checks. Every result comes back looking perfectly reasonable.

Which is the same failure people hit with a mismatched embedding model, with no machine learning anywhere near it. So write down whatever turns your data into numbers, keep it next to the index, and version it. When it changes, re-derive the lot.

Have a go

The full write-up for the store locator is on accesspatterns.dev, and there's a geohash-only version of the same seven shops if you want to poke at the prefix read on its own. Everything runs on dynoxide's WASM engine, so there's no account and nothing goes near AWS.

I did two of Harding's other cases the same way if you want them. Sensor fusion is five sensor channels on wildly different scales, where the numbers need normalising before the distance means anything at all, and it's the clearest illustration of the point above. Design tokens matches a pasted hex to the nearest approved colour, where converting to CIELAB makes the distance function a consequence rather than a choice.

And if you've got a geohash doing proximity in production, it's worth firing a few queries near a cell edge and looking at what comes back. It won't tell you it's missing anything.

Running DynamoDB vector search locally

Martin Hicks — Tue, 08 Sep 2026 07:21:32 +0000

Dynoxide has had DynamoDB vector search since 1.0.0 landed on the 25th of August: vector indexes, SearchVectors, and the write paths keeping them current. It's on the native binary, the browser build and the MCP server, so an agent can create an index and search it without any of that reaching AWS.

I announced it at the time and then went on holiday instead of writing it up. This is the write-up, plus 1.1.0, which landed on the 3rd.

The index says ACTIVE about fifteen minutes early

Before building any of it I spent two days pointing things at real DynamoDB and writing down what came back, because I wanted vector search in the conformance suite and the docs didn't agree with themselves about when an index is ready.

Add a vector index to a table that already has data in it and it has to backfill. Fine, expected. So you poll DescribeTable and wait for IndexStatus to reach ACTIVE, which is what you'd do for a GSI and what AWS's docs told you to do at the time.

It reaches ACTIVE, you search it, and it refuses.

On a table with twenty-five items in it, that carried on for about a quarter of an hour.

Dynoxide does the same thing, deliberately. The index goes ACTIVE, searches still get refused, and a while later it starts answering. A readiness check built on polling for ACTIVE therefore breaks on your laptop rather than in production. Put the search in a retry loop and treat the refusal as "not yet".

The full lifecycle, for reference:

Phase	`TableStatus`	`IndexStatus`	`Backfilling`	`SearchVectors`	Delete of the index
Allocating	`UPDATING`	`CREATING`	`false`	refused	refused
Backfilling	`ACTIVE`	`CREATING`	`true`	refused	accepted
Active, not searchable	`ACTIVE`	`ACTIVE`	absent	refused	accepted
Searchable	`ACTIVE`	`ACTIVE`	absent	served	accepted

The base table catches people out too. It's back to ACTIVE while the index is still CREATING, so a table waiter looks like the right gate about three phases too early.

And Backfilling doesn't go false when it finishes, it disappears. Which means "wait until IndexStatus is ACTIVE and Backfilling is false" never comes true, on AWS or here. That was AWS's own documented advice until they rewrote it.

Timings are the one thing not to copy across. Dynoxide's phases run in tens of seconds so you can watch them happen; AWS's are minutes and vary with the table. Don't write sleep(30) and assume you're ready.

Where it won't ever match

Dynoxide compares your query against every vector in the index, so you get the genuinely nearest results back. AWS builds an approximate index and skips most of the comparisons, which is how it stays quick on a huge table and why it will occasionally miss something that was really there. So don't pin an exact list of results in a test that also runs against AWS - assert what you actually care about, like "the item I put in comes back". It also means a local table holding millions of vectors isn't what this is for.

Ties are the other one. Dynoxide breaks them by primary key, AWS promises nothing, and three identical calls came back in three different orders. Sort them yourself if it matters.

My favourite is VectorSearchRequestBytes, where AWS can't reproduce its own number. Five identical searches over an index nobody had touched: 14214, 13903, 14214, 14214, 14518. Dynoxide reports something stable instead, which is handy for comparing one local search against another and useless for asserting against AWS.

Three months watching one error message

1.1.0 is a single behaviour change, and it's the end of something I started writing about in June.

Back then my conformance suite went red and the thing that failed was AWS. It had quietly reworded a pile of its validation errors, with nothing in any changelog. I checked four regions: two had the new wording, two didn't. I said I reckoned that was a rollout caught mid-flight rather than a permanent regional split, and that I had no way to prove it.

The suite sweeps 33 regions now. As of the 2nd September, BatchGetItem with an empty RequestItems map answers the new wording in 32 of them, and me-central-1 is the last holdout. So it was a rollout, and it took about three months.

The part I didn't see coming is that it moves per operation as well as per region. BatchWriteItem sits right beside it, takes the same empty map, hits the same validation, and is still on the old wording nearly everywhere - one region, eu-north-1, had crossed as of the 22nd August. Dynoxide follows eu-west-2, so one of the pair changed in 1.1.0 and its sibling didn't. They answer differently now, with a test pinning each, because that's what the real thing does.

The boring bits

1.0.0 carried a lot besides vector search. Consumed capacity is sized the way DynamoDB sizes it now, a stack of PartiQL fixes landed, and several requests that used to be accepted aren't any more. If you've got tests asserting on exact answers, read the changelog before you upgrade.

One worth calling out on its own: StorageBackend is sealed. Vector indexes alone added seven methods to that trait, and left open, every one of those would have been a major.

Everything moved to 1.0.0 together and the browser engine dropped its -preview suffix. That number isn't a claim that conformance is finished - the live standings are the honest answer to that.

Get it

npm: npm install --save-dev dynoxide to pin it in a project, or npx dynoxide to run the latest without installing
Homebrew: brew install nubo-db/tap/dynoxide
Cargo: cargo install dynoxide-rs (crates.io, docs.rs)
Docker: ghcr.io/nubo-db/dynoxide, mirrored best-effort to Docker Hub (nubodb/dynoxide) and ECR Public
GitHub: source and pre-built binaries, plus the nubo-db/dynoxide/action GitHub Action for CI

When a DynamoDB vector index is actually ready

Martin Hicks — Thu, 13 Aug 2026 16:07:07 +0000

AWS shipped vector search for DynamoDB on 5th August, straight to GA. I spent a couple of days pinning it down against real DynamoDB so I could add it to my conformance suite, which meant reading the docs properly and then checking whether they were true.

Mostly they are. But there's one thing they get wrong three different ways, and the three stack up: knowing when a vector index is ready to search.

The tutorial contradicts everything else

Add a vector index to a table that already has data in it and there's a gap before you can use it, while DynamoDB backfills the index from the items you already have. What happens if you search during that gap depends on which page you read.

Three pages say you get an error. The data synchronisation page puts it plainly:

New writes to the base table are replicated to the index during this phase, but SearchVectors returns an error until backfilling finishes.

Creating and searching has a callout headed "You can't search while the index is backfilling", and troubleshooting carries a row for it. The tutorial says something different:

Searching an index that is not yet ACTIVE fails, and searching during backfill can return incomplete results.

Those aren't the same problem at all. An error you catch and retry. Incomplete results you can't spot, because a short answer from an approximate search looks exactly like a short answer from a thin index. If the tutorial were right, every search during a backfill would be quietly wrong with nothing to tell you.

It isn't right. You get an error, and there are two of them depending on how far along the index is:

ValidationException: The table does not have the specified index: vix
ValidationException: Cannot search backfilling vector index: vix

So trust the other three. Worth saying out loud, because the tutorial is the page you'd be following if this is your first vector index.

The state machine doesn't exist

This is the one that would actually bite.

Those three pages all describe the index moving through the same three states: CREATING while DynamoDB sets up the infrastructure, then a middle state, then ACTIVE with Backfilling: false once it's done. The data synchronisation page names the middle one:

It then moves to IndexStatus ACTIVE with Backfilling set to true while DynamoDB populates the index from existing base table data.

Every piece of waiting advice in the documentation hangs off that state.

I polled DescribeTable every five seconds through the creation of an index added to a table that already had items in it. This is what I got:

CREATING   Backfilling: false
CREATING   Backfilling: true
ACTIVE     Backfilling: (gone)

There's no middle state. Backfilling is a CREATING-time field, and when the index flips to ACTIVE the field doesn't settle to false, it vanishes from the response.

That breaks the advice, because the advice tells you to wait for a value that never arrives. Data synchronisation again, in the sentence straight after the one I quoted earlier:

Use DescribeTable and wait until IndexStatus is ACTIVE and Backfilling is false before you search.

Write that literally and your poll never finishes. By the time the status is ACTIVE, Backfilling is undefined, not false. One page out of the four allows for that, and it does it in a parenthesis: "Backfilling set to false (or absent)".

Create the index as part of CreateTable instead of adding it later and the field never turns up at all. That one I do assert, on every poll, so if AWS starts reporting it my tests break:

expect(ix?.Backfilling).toBeUndefined()

Let me be straight about the evidence, though, because the two halves aren't equally solid. That assertion is real and runs on every scheduled run. The three-line transcript above isn't pinned: it's something I recorded on 11th August, and the test only checks the field showed up at some point, without checking that true appears solely alongside CREATING. It's in the capture file with the documented version quoted next to it if you want to check the mismatch yourself. A gap in my tests rather than in the finding, and it's on the list.

ACTIVE arrives too early

Even once the status says ACTIVE, the index can still not be ready.

DescribeTable goes ACTIVE a beat before the search plane agrees. Search on that first ACTIVE and you get failures that look like flakiness and aren't. It's a small window, which is worse than a big one: a window small enough to survive your local testing still opens wherever things run fastest.

That bites hardest when you create the index with the table, because there's no Backfilling field on that path and the tutorial tells you to go on status alone:

Use IndexStatus alone as your signal in that case.

Status alone is the signal that arrives early.

How to wait for it properly

Prove the index is ready with a search, not with a description. My suite polls until a search comes back with everything it put in:

while (true) {
  try {
    const res = await ddb.send(new SearchVectorsCommand({
      TableName, IndexName, SearchVector, TopK: 5,
    }))
    if ((res.SearchResults ?? []).length === expectedCount) break
  } catch (err) {
    // Not ready yet. Anything else is a real failure.
    if (err.name !== 'ValidationException') throw err
  }
  await new Promise(r => setTimeout(r, 5000))
}

The count check earns its place as much as the try/catch does. A search can start succeeding while the index still has a partial view of your data, so a bare "did it throw" test lets you through early with fewer results than you wrote.

Budget some time for it too. An index added to a table holding 25 items took about 17 minutes to become searchable. It's running on the same online-index machinery as a GSI, and the size of the table isn't what drives that number. It inherits the GSI concurrency limit as well, error message and all:

LimitExceededException: Subscriber limit exceeded: Only 1 online index
can be created or deleted simultaneously per table

Other things worth knowing

The index keeps your embeddings at f32 and the table doesn't. The docs do say this, so it's not a discovery, but it's worth seeing how big the gap is. 16777217 is the first integer a 32-bit float can't hold. Write it into an embedding and the base table gives it back exactly. Ask for the same attribute through a search projection and you get 16777216. The index also prints its f32 copy as the shortest decimal that names the float, so 0.1 comes back as 0.1 rather than 0.100000001490116119384765625, which makes the whole thing harder to notice than it sounds.

Vector capacity has a shape nothing else in DynamoDB uses. A search reports a bare object with no capacity units and no table name:

{ VectorSearchRequestBytes: 1024 }

Writes report a VectorIndexes map, but only under ReturnConsumedCapacity: 'INDEXES'. Ask for TOTAL and you get nothing vector-related at all, not even rolled into the total, so the two modes aren't detail levels of the same number here.

That 1024 is interesting on its own. A three-dimension vector is twelve bytes of f32, so it looks like a 1KB floor rather than anything to do with the size of your vector. One run isn't enough to assert a formula, so my tests check it's positive and stop there.

No emulator implements any of this yet. I score eight DynamoDB emulators against real AWS on every run and all eight skip the whole family. DynamoDB Local is the one to watch: it takes VectorIndexes on CreateTable quite happily and then silently drops them, so a DescribeTable afterwards shows no indexes at all. If you're testing locally against it, the vector index you think you created isn't there.

You need a recent SDK. @aws-sdk/client-dynamodb 3.1103.0 or later.

The evidence

Both sides of the backfill contradiction are in captures/2026-08-12-vector-backfill-docs.json, dated, with their URLs and anchors, along with the documented state machine, the transcript that doesn't match it, and which of the two paths is pinned by an assertion. Check any of it rather than taking my word for it.

The tests live in the same repo under tests/tier2/vectorSearch and run against real DynamoDB on a schedule, so if AWS changes something here I'll find out. If you've hit anything else in it, tell me and I'll add a test.

What a write to an indexed DynamoDB table costs

Martin Hicks — Thu, 13 Aug 2026 16:07:04 +0000

My conformance suite has had a per-index capacity assertion since fairly early on. It was on a Query.

Which is the wrong half. Reading through an index is the cheap, obvious, well-understood part. The write side is where a secondary index actually costs you money, because every write to the base table fans out to every index the item lands in, and you pay for each one. That went unmeasured for months, until spaceemotion filed an issue pointing straight at the gap and listing the four cases it needed to cover. All four are below.

So I fixed it, and measured the lot against real DynamoDB in eu-west-2. Fourteen tests, every integer below observed rather than lifted from the docs.

The setup

One on-demand table, a composite key, and two indexes chosen so each one can be isolated:

KeySchema: [
  { AttributeName: 'pk', KeyType: 'HASH' },
  { AttributeName: 'sk', KeyType: 'RANGE' },
],
GlobalSecondaryIndexes: [{
  IndexName: 'gsi-inc',
  KeySchema: [{ AttributeName: 'gsiPk', KeyType: 'HASH' }],
  Projection: { ProjectionType: 'INCLUDE', NonKeyAttributes: ['proj'] },
}],
LocalSecondaryIndexes: [{
  IndexName: 'lsi1',
  KeySchema: [
    { AttributeName: 'pk', KeyType: 'HASH' },
    { AttributeName: 'lsiSk', KeyType: 'RANGE' },
  ],
  Projection: { ProjectionType: 'ALL' },
}],

The GSI uses an INCLUDE projection carrying exactly one non-key attribute, proj. That's what gives the update tests a lever: I can touch an attribute the GSI projects, or one it doesn't, and watch the difference. The LSI projects everything, which sets up the mirror case.

Every item is under 1KB, so each index write is exactly one unit and the arithmetic shows structure rather than rounding. Every test seeds a fresh key, for a reason that becomes obvious further down.

All of it read back with ReturnConsumedCapacity: 'INDEXES'.

The basic shape

A write costs one unit for the table, plus one for each index it lands in.

Write	Table	GSI	LSI	Total
Item with both index keys	1	1	1	3
Item with the GSI key only	1	1	-	2
Item with the LSI key only	1	-	1	2
Item with neither	1	-	-	1

Two things there are worth stating plainly because the docs are vague on both.

LSI units fold into the top-level total exactly as GSI units do. I'd half expected local indexes to be free on the write path, given they share a partition with the item. They aren't.

And a write that costs an index nothing reports no arm for that index at all. Not a zero:

// Sparse write, misses both indexes
{
  CapacityUnits: 1,
  Table: { CapacityUnits: 1 },
  // GlobalSecondaryIndexes: absent
  // LocalSecondaryIndexes: absent
}

If you're summing arms to reconcile a bill, absent and zero need the same handling, and a naive Object.keys(cc.GlobalSecondaryIndexes) throws rather than returning nothing. That's the sort of thing that survives testing right up until a sparse write shows up in production.

Two more shape notes. Under ReturnConsumedCapacity: 'TOTAL' you get the correct total and nothing else, with no Table field and no index arms. And under INDEXES, the arms you do get carry only an aggregate CapacityUnits, with no read/write split inside them.

The update ladder

This is the interesting part, and the part I'd get wrong if I were guessing.

Updating an item costs the index nothing, one unit, or two, depending entirely on what you touched. Same item, same table, four different updates:

Update	Table	GSI	LSI	Total
`SET other = :v` (not projected by the GSI)	1	-	1	2
`SET proj = :v` (projected by the GSI)	1	1	1	3
`SET gsiPk = :v` (moves the GSI key)	1	2	1	4
`REMOVE gsiPk` (leaves the GSI)	1	1	1	3

The two-unit row is the one to internalise. Changing an item's GSI partition key isn't an update on that index, it's a delete from the old partition and an insert into the new one, and you pay for both. So a status attribute that doubles as a GSI key costs two index writes on every transition, not one, and a workflow that moves an item through several states pays that each time.

Removing the key costs one, because there's a delete and no insert.

The first row shows the projection doing its job: other isn't in the GSI's INCLUDE list, so the GSI's stored copy of the item didn't change and the GSI charged nothing. The LSI still charged one, because it projects ALL and its copy did change.

That mirror case holds in the other direction too. Updating the LSI's sort key costs the LSI two, a delete and an insert, and costs the GSI nothing, because lsiSk sits outside the GSI's projection:

Update	Table	GSI	LSI	Total
`SET lsiSk = :v`	1	-	2	3

So the rule underneath all of this is not about keys or attributes as such. An index charges you when the bytes it stores change, and the projection decides which bytes those are. A wide projection is a bigger write bill on every update, not just a bigger index.

One caveat if you're scaling any of this up. Every item here is under 1KB, so each charge is a single unit and the ladder shows structure rather than rounding. Above 1KB the shapes stop agreeing: an in-place entry update and a key move are no longer the same arithmetic, and the ladder's integers stop generalising. I've measured where they diverge and I'll write that up separately with the capture behind it.

The overwrite that costs nothing

Put an item, then put the identical item again:

const item = {
  pk: { S: 'k' }, sk: { S: '1' },
  gsiPk: { S: 'g4' }, lsiSk: { S: 'L1' }, proj: { S: 'p' },
}

await put(item)   // total 3: table 1, gsi 1, lsi 1
await put(item)   // total 1: table 1, no index arms at all

The second write charges for the table and nothing else. Index replication is delta-based, so re-writing bytes an index already holds costs nothing on that index.

This is why every test in the file seeds a fresh key. I lost an hour to a test that passed alone and failed in the suite, because a retry was overwriting an item it had already written and getting a legitimately smaller bill for it.

Practically, this makes idempotent writes cheaper than they look. A retry loop that re-puts the same item is paying for one table write per attempt, not the full fan-out. It also means you can't infer index cost from write volume, because a workload that rewrites unchanged records has an index bill near zero.

The same behaviour shows up on DynamoDB's new vector indexes, where an overwrite with an identical embedding reports no vector write capacity whatsoever. Same replication layer, presumably.

Deletes and batches

Deletes mirror puts. One unit for the table, one for each index the item occupied:

Delete	Table	GSI	LSI	Total
Item that was in both indexes	1	1	1	3
Item that was in neither	1	-	-	1

BatchWriteItem reports one entry per table with the arms the batch actually touched, aggregated. Two puts in one batch, one indexed and one sparse:

{
  TableName: '...',
  CapacityUnits: 3,
  Table: { CapacityUnits: 2 },      // both items
  GlobalSecondaryIndexes: { 'gsi-inc': { CapacityUnits: 1 } },  // one item
}

The table arm counts both writes, the index arm counts only the one that landed in it. There's no per-item breakdown, so a batch is the point where you stop being able to attribute cost to a specific write.

What I'd take from it

The headline number people carry around is "an index roughly doubles your write cost", and that's about right for a table with one index where every item carries the key. It stops being right in both directions fairly quickly.

A sparse index costs nothing on writes that miss it, which makes sparse indexes cheaper than their read behaviour suggests. A narrow projection costs nothing on updates that don't touch projected attributes. And an attribute that's both a GSI key and a mutable field is the expensive shape, because every change to it is two index writes rather than one.

If you want the numbers for your own schema rather than mine, ReturnConsumedCapacity: 'INDEXES' on a scratch table is a twenty-minute exercise and it will tell you more than the docs will. The tests behind this post are in paritysuite/dynamodb-conformance under tests/tier1/putItem/indexConsumedCapacity.test.ts, and they re-run against real DynamoDB on a schedule, so if any of these integers move I'll know.

On their first run those tests put ten failures against Dynoxide, my own engine, scored by the same suite.

Parity Suite 3.0.0: measuring the wrong thing

Martin Hicks — Thu, 13 Aug 2026 15:05:47 +0000

Since the board started it has published one number per emulator: a pass rate over the tests that emulator attempted. Skipped tests left the sum entirely.

Which means the number could move without the engine changing a line. In July one emulator gained 8.4 points having shipped nothing at all.

3.0.0 replaces that number. Two figures instead of one, a letter grade on every target, and the suite is up to 1,054 tests with the first coverage of DynamoDB's new vector search.

Two figures, never added together

Coverage is how much of DynamoDB the emulator supports. Divergence is how much of it the emulator gets wrong. Both are measured over the whole suite, so neither can hide inside the other.

They're reported apart because a skip and a fail are different problems. An operation your emulator declines is something you find in minutes and plan around. One it gets quietly wrong is something you find in production.

The July case was Dynalite, and it works as an example precisely because Dynalite did nothing. It passed 673 tests before and 673 after. Two things happened, both of them mine.

First I grew the suite by 44 PartiQL tests Dynalite doesn't implement. Every one landed as a skip, and the old number didn't move at all, because skips left the sum entirely. The job got 44 tests bigger and the score couldn't see it.

Then I improved the probes that spot Dynalite doesn't do transactions, which turned 88 failing tests into skips. That the old number could see. It climbed from 76.0% to 84.3%, and I published an 8.4 point gain for an engine nobody had touched.

Under the new figures both show up. The transaction reclassification drops divergence and coverage by 8.8 points each, together, measured over the suite as it stood in July. The suite growth drops coverage while divergence barely moves, which is what "the target didn't change, its job got bigger" should look like.

Nothing was re-run for this. No pass, fail or skip changed, so a figure that looks different from last month is the same measurement described better.

Letter grades

Two figures are harder to skim than one, so every target wears a letter as well.

Divergence sets it: A under 5%, B under 15%, C under 25%, D under 35%, F beyond. Coverage can only pull it down. A third of whatever a target leaves unimplemented is added to its divergence before the bands are read, so an engine covering the whole suite is graded on divergence alone.

A+ is zero divergence at full coverage.

The criteria are versioned and dated in the methodology. Moving a threshold regrades engines whose results never changed, and that should be a visible act rather than a quiet edit.

The board today

Dynoxide is mine, so a board I author has my own engine at the top of it. The disclosure sits on the card and on the methodology page, and the oracle is derived at build time rather than by me.

Target	Grade	Divergence	Coverage
DynamoDB	baseline	0.0%	100.0%
Dynoxide · native	A	0.9%	94.7%
↳ WebAssembly / OPFS	B	0.9%	83.4%
ExtendDB · PostgreSQL	B	2.2%	87.8%
Ministack	B	11.9%	96.0%
Dynalite	C	12.8%	77.0%
LocalStack	C	14.8%	95.3%
DynamoDB Local	C	15.1%	94.0%
Floci	C	21.0%	95.2%

Those are the 12th August run. The board re-runs against live AWS on a schedule, so the live figures are the ones to trust if these have moved.

Dynoxide had zero divergence before this release. It's at 0.9% now, and all ten of its failures are in tests/tier1/putItem/indexConsumedCapacity.test.ts, a file this release added after spaceemotion filed an issue pointing out that the suite wasn't measuring index write costs at all. The tests caught ten Tier 1 failures in my own engine on their first run, and the board published them the same day. Tier 1 is the tier the suite describes as what most DynamoDB users rely on, so that's the worst place to find them.

Real DynamoDB reads baseline rather than a letter and sits in a panel above the standings now. Grading the yardstick against itself would put it in a band the engines have to earn.

Dynalite and LocalStack are both being held down by coverage. Each would be a B on divergence alone, and in both cases the coverage shortfall drops them to C. Their rows say so, because the two Cs on the board aren't the same shape of C.

How to actually use it: if you need specific operations, ignore the letter and go to the target's page, where What it doesn't attempt names the coverage gap directly. That's the answer to "will this emulator do what my app does". If you're picking blind for general CI use, the letter is the shortlist and divergence breaks the tie, because a high-coverage engine that gets things wrong will cost you more debugging than a narrow one that's honest about its limits.

What's new in the suite

Vector search. AWS shipped it on 5th August and the suite covers its deterministic surface as of this release: 42 tests, all characterised against real DynamoDB in eu-west-2 first. The interesting part was index readiness, where the documentation is wrong three separate ways: the pages contradict each other on what a premature search does, they describe a Backfilling state the index never enters, and the status they tell you to wait for arrives before the index can answer. That's written up in when a DynamoDB vector index is actually ready, with both sides of the contradiction captured in the repo. No emulator implements any of it yet, so every coverage figure on the board dropped when these landed, while divergence stayed untouched.

Index write costs. The suite's only per-index capacity assertion was on a Query, so the write side, the half you get billed extra for, went unmeasured. Fourteen new Tier 1 tests fix that. Moving an item to a new GSI key costs two units on that index rather than one, and an overwrite that changes nothing costs nothing at all. The full set of numbers is in what a write to an indexed DynamoDB table costs.

Housekeeping

A target's page should be readable by someone who's never seen the project. How to run it lists every way the target is distributed, Docker image, npx, cargo, a JAR, each linking to the project's own page. What it doesn't attempt names the coverage gap. Builds of an engine now nest underneath it rather than taking a row alongside.

The history chart split into two plots. One line couldn't be trusted on its own, because divergence falls whenever tests a target used to fail stop being run against it, which is how July rendered as an improvement.

Tier bars use length for coverage and colour for divergence. Movement reads 4.9pp less instead of -4.9pp. Every heading on the prose pages has an id you can link to.

The badges were still publishing the correctness percentage the board had retired, so a badge could disagree with the table it linked to. They show the grade now, on the same URL.

Corrections

The methodology page used to claim that measuring over the whole suite stopped a thin emulator posting a perfect score. It doesn't. Zero fails is 0.0% at any coverage, which is exactly why the grade caps on coverage instead.

The baseline row was overstating itself. Real AWS runs in three passes and only the main one reached the published artefact, so the row claimed 998 of 998 on a run that recorded 981. The passes are merged before scoring now, and the row stays pinned and says so until all three report.

The suite counts its own tests. Until this release "the whole suite" meant whichever target had run the most tests, which put one of the measured things in charge of everyone else's denominator. There's a generated manifest of all 1,054 now, and CI fails if it drifts from the tests.

What breaks

JSON consumers. The data endpoints jump two schema versions. Anything still on 2 gets both breaks at once, and there are four of them.

The dangerous ones are movement.state and movement.delta. State's values changed from up/down to improved/regressed, so the old names still parse and now mean the opposite direction. Delta inverts the same way without changing shape, so the sign means the opposite of what it did and nothing in the data says so.

The other two announce themselves. A tier carries divergence, coverage and correctness instead of a bare pct and value, and the whole-suite correctness percentage is correctness rather than total, which also named a raw count elsewhere in the same payload.

Correctness is still published under its own name, so anything built on the old figure keeps working. It just isn't the headline any more.

The full notes are in the 3.0.0 release, the suite is at paritysuite/dynamodb-conformance, and the board itself is at paritysuite.org.

The tests and the scoring code are both in the repo. If something looks wrong, an issue is welcome.

Learn DynamoDB by running it - accesspatterns.dev

Martin Hicks — Tue, 30 Jun 2026 21:20:59 +0000

I've been building on DynamoDB since around 2015, and these days I build tools for it: dynoxide, a DynamoDB engine, and Nubo, a native client. So I'm not neutral about it. It's the first database I reach for, and with reason - the operational overhead is close to nil, no connections to pool or instances to size, and it holds the same single-digit-millisecond reads whether the table has a thousand items or a billion. The data modelling is a craft, and a satisfying one.

It's also one of the harder databases to learn, and that's the part I keep coming back to. DynamoDB punishes the instincts you bring from SQL. You don't normalise and join at read time; you work out the questions your app will ask first, and shape the data around those access patterns, until one table answers all of them. It's a real shift in how you think, and it's where a lot of people bounce off - it feels backwards right up until it clicks.

The people who teach it best all teach it the same way. Alex DeBrie's The DynamoDB Book, the arc.codes team's examples, Rick Houlihan's re:Invent talks - the legendary ones, where he models half a dozen access patterns onto a single table at a hundred miles an hour - none of them hand you rules to memorise. They show you patterns and make you run them. I learned a lot of my DynamoDB from all three, and it stuck because I was building as I went.

That last part is the bit that's hard to come by on your own. Reading about an access pattern and having it in your fingers are different things, and to run one - build the table, write the items, fire the query and see what comes back - you need an AWS account, or a local emulator installed and seeded. Enough friction that plenty of people read about single-table design without ever building one.

There was a second thing pulling the same way. dynoxide had learned to run in the browser only last month, compiled to WebAssembly with no server behind it, and it was a preview I didn't fully trust. What it needed was a real, demanding consumer: something that would lean on the wasm engine hard enough to find where it broke, not a handful of tests that politely agreed with it.

Both of those pointed at the same project, and accesspatterns.dev is what came out of it: a place to learn DynamoDB that also happens to be a working app sat on the engine all day. That's where the past month went, and why 0.11.0 took as long as it did - building on it in earnest is what turned up the bugs that release fixed.

What you get out of it is the thing I wanted from the start: the friction is gone. Open the page and the engine is already there with a table in it. Query one customer's orders and you get exactly those back, because in DynamoDB the key is the address; run the same question as a scan and it reads the whole table and throws most of it away. Same answer, very different work, and you've seen it for yourself rather than taken it on trust.

There's more to it than that, though. A course of about twenty lessons takes you from your first GetItem to single-table design, each one something you build and try rather than just read. Beyond it sit a handful of worked models - a game leaderboard, a SaaS multi-tenant table - to load up and pick apart, closer to what you'd actually ship than the usual textbook example. And underneath everything is a full console: assemble any operation, fire it at the table, and lift the request straight out as JavaScript SDK v3, boto3 or AWS CLI code for your own app.

How it works

It all runs on dynoxide compiled to WebAssembly, in a Web Worker in your tab: the same engine that backs the native build, the same SQL underneath, now packaged on npm as the thing accesspatterns.dev depends on. There's no backend, so every query, scan and write runs client-side against a SQLite-backed store. The database is in the tab, which is why it needs no account and nothing to install.

It's a preview. The wasm build doesn't yet run against the conformance suite that holds dynoxide's native build to real DynamoDB, so treat what you see as illustrative rather than authoritative. Building accesspatterns.dev on it is what's been hardening it; getting the wasm engine onto that suite is the next job, and the day it's there is the day the preview label comes off.

It's early, and the part I most want to grow is that library of models. I'd rather it weren't only mine. A shared, runnable catalogue of how people actually model their own problems on DynamoDB would be worth far more than my handful of examples, and that's the direction I want to take it. There's no way to submit one yet, but if you've got a pattern you'd want in there, tell me - and if something behaves wrong, tell me that too. It's the same dogfooding that got the engine this far.

How close is your DynamoDB emulator to AWS?

Martin Hicks — Wed, 27 May 2026 14:21:30 +0000

My DynamoDB conformance suite has a site now: dynamodb-conformance.org. Eight emulators, 684 tests, scored against live AWS DynamoDB.

The README only ever showed a single snapshot, frozen at whenever I last updated the table. The site shows everything around that snapshot. The homepage is the standings - every target ranked by how closely it matches real DynamoDB, with DynamoDB itself pinned at the top on a flat 100%. Each emulator gets its own page with run-over-run history - not just where a score landed, but where it moved and which tests pushed it. There's a support matrix that breaks every operation down target by target, and a runs archive going back through each scoring pass. Want to know whether LocalStack handles transactions, or where DynamoDB Local diverges on error wording? It's a couple of clicks now, not a repo checkout.

How it works

Every test runs against live AWS DynamoDB first. Whatever the real thing does is recorded as the expected answer, and an emulator only passes if it gives that same answer. The ground truth is never my reading of the docs - it's what DynamoDB actually returned when I asked it.

The results split into three tiers, because one number hides too much. Core is the everyday stuff: CRUD, queries, scans, batch operations. Complete adds the documented-but-less-common features like transactions, PartiQL, TTL and streams. Strict is the fiddly end - validation ordering, exact error wording, API limits, legacy shapes. A gap in Core breaks your app. A gap in Strict breaks the CI test that asserts on an error message.

Everything is checked through the standard AWS SDK against the target's HTTP endpoint. Nothing reaches inside the implementation. If your application would see it through the SDK, the suite checks it. If it wouldn't, it doesn't care.

And the suite grows. New tests land most weeks, so a score can move because the target changed or because I added coverage that exposed an old gap. A high score only means the target passes the tests that exist; behaviours the suite doesn't cover yet are blind spots, not passes. The methodology page has the full version.

What this run shows

The figures below come from the run dated 26 May 2026 - the site always shows the current ones.

Take LocalStack. It sits at 88% overall, which reads as middling until you split it: 98.6% on Core, 68.7% on Strict. That's not a mediocre emulator, it's a genuinely good one for everyday work that comes apart on error fidelity. The headline number flattens two completely different shapes of gap into one figure, which is precisely why the tiers exist. DynamoDB Local lands in almost exactly the same place - 97.7% Core, 69.2% Strict - which is no coincidence: LocalStack runs it under the hood. Same engine, same gaps, right down to the tier split.

This run also shows the suite breathing. It grew by 29 tests this pass, and the biggest movers all went down - Floci off 1.3 points, Dynalite 1.2, ExtendDB 1.1. Nothing regressed. The new tests just went looking where the old ones hadn't. That's the suite doing its job: coverage sharpens, scores dip, targets fix the gaps and climb back.

One result is worth singling out. Ask real DynamoDB for item collection metrics on a write with ReturnItemCollectionMetrics: SIZE and it hands them straight back. Ask DynamoDB Local, LocalStack, Dynalite or Ministack and you get silence - a documented response field they simply don't implement, AWS's own emulator included. Dynoxide, ExtendDB and Floci return it correctly. You'd never know unless something was checking.

Run it yourself

The whole thing is Apache-2.0 and every test is in the repo. Anything that speaks the DynamoDB HTTP API can be scored, so if you maintain an emulator, clone it, point it at your endpoint and see what comes back. You'll almost certainly find something. If you'd rather just see your emulator on the board, there's a suggest a target form.

If you spot a behaviour the suite doesn't cover yet, send a PR. The single rule is that the test has to pass against real DynamoDB first - if AWS rejects it, the test is wrong, not the emulator. That rule is the whole point. Targets are measured against real DynamoDB, never against each other, so two emulators agreeing on the same wrong answer can't quietly make it the standard. The suite is meant to be an independent reference the whole field can trust, not something any one project owns. No emulator author, me included, gets to mark their own homework.

And the field is genuinely getting good. Floci has come a long way since late April, from around 61% to the low 90s, with its Tier 3 score hauled up out of the twenties. ExtendDB only joined in late May and landed near the top straight away. It's an AWS-managed open-source project, Postgres-backed, that speaks the DynamoDB wire protocol. Worth a look.

Dynoxide, my own engine, sits in there on the same terms as the rest: same tests, no favours. Floci and ExtendDB are a couple of points behind and still climbing, and the whole field is closing on real DynamoDB.

Filing my first security advisory

Martin Hicks — Tue, 12 May 2026 15:02:50 +0000

Yesterday I logged into GitHub and noticed a Dependabot alert sitting on dynoxide. DNS rebinding CVE in rmcp, a transitive dependency. The alert had been raised a few days earlier - I just hadn't seen it, because I'd never set up email notifications for Dependabot on that repo. First lesson of the day, before the actual lesson of the day.

I worked through the fix and published a GitHub Security Advisory once the patch release was out. The fix itself was the bit I knew how to do. The GHSA was new ground, and that's the part I want to write about, because if you maintain something with users and you've never filed one, the process is less daunting than I'd built it up to be.

The notification gap

Worth dealing with this one first.

Dependabot raises alerts on your repo's Security tab automatically. By default, GitHub doesn't email you about them - they appear on the dashboard and that's it. If you don't log into the affected repo regularly, you won't see them.

The fix is at the repo level. Top right of the repo page, hit Watch → Custom, then tick Security alerts. You'll start getting emails for security events on that repo.

I can see why this isn't the default. If you've forked a load of old projects you don't actually maintain, the last thing you want is an inbox full of alerts for repos that aren't yours. The cost of that default is that on the repos you do maintain, you have to opt in deliberately. I hadn't.

There's a second timing thing worth knowing about. Even with email notifications set up, there's a gap between the upstream CVE being published and your Dependabot alert firing. For mine, the upstream rmcp advisory was published on 29 April. My Dependabot alert came through about nine days later. GitHub's Advisory Database reviews advisories before they propagate, and Dependabot itself runs on a scan schedule. The delay is mostly outside your control. Knowing it exists at least means you don't panic when you discover the upstream advisory predates your own alert.

What a GHSA actually is

A GHSA is a structured record on your repo's Security tab. Affected package, affected version range, fixed version, severity, CVSS vector, weakness category, description. The structure matters because of what happens when you publish it: GitHub's advisory database picks it up, and every downstream project that depends on your package gets a Dependabot alert. Often an automated upgrade PR.

In my case this was the whole point. The named CVE lives in rmcp. Anyone with a direct rmcp dependency already had an alert from the upstream advisory. But dynoxide users have rmcp transitively - it's in the lockfile, not the manifest - and the upstream alert doesn't fire for them. Without a dynoxide-specific GHSA naming the affected version range of dynoxide-rs and dynoxide, nothing reaches those users automatically.

The GHSA isn't ceremony. It's the actual distribution mechanism.

Order of operations

Release first, advisory second.

The advisory references the patched version. Dependabot's upgrade PRs for downstream projects will fail if that version doesn't exist on the registry yet. If you publish the GHSA before the release is live, you've broadcast "upgrade to a version that doesn't exist" to every project that depends on you.

So: cut the release, wait for CI to push to the registries, verify the patched version is actually available, then publish the advisory. The save-as-draft option on the GHSA form is there for this reason.

Last step is the social post, after opening the GHSA URL in a private window to check a logged-out viewer can actually see it. Until you hit publish, the advisory is only visible to repo admins and the URL returns nothing useful to anyone else.

Filing the form

The form lives at Security → Advisories → New draft security advisory. A few things that tripped me up.

Ecosystem. The dropdown doesn't list "cargo" - it lists "Rust". I scrolled past it twice. The mapping is to crates.io under the hood. npm is named npm.

Package names. Must match the registry exactly or Dependabot doesn't fire. GitHub validates this and shows a small "Package name found on Rust" confirmation when it's right. For dynoxide that's dynoxide-rs (the Cargo crate, because the name dynoxide was already taken) and dynoxide (npm).

Version ranges. Cargo-style semver: >= 0.9.3, < 0.9.13. I started at 0.9.3 because that's when the MCP HTTP transport landed. Earlier versions don't expose the vulnerable surface, so flagging them would just generate noise alerts for users on older versions who aren't actually affected.

CVE. The upstream CVE-2026-42559 already exists. There's a field for "I have an existing CVE ID" - use it. Don't request a new one for the same root cause.

CVSS. This was the field I felt least sure about. There's an in-form calculator and I had a go at deriving my own vector for dynoxide's exposure context. I marked Attack Complexity as High because the rebinding chain felt fiddly to me. That was wrong - upstream marked it Low, and Low is right, because public DNS rebinding tooling makes the attack cheap to execute. My score came out at 7.5 instead of upstream's 8.8.

The mistake was easy to make and easy to fix (GHSAs are editable after publishing), but it would have saved me both the agonising and the error to just match the upstream score in the first place. For a transitive-dep advisory where the exposure mechanism is essentially the same as upstream, divergent scores just confuse downstream readers. Match upstream unless you've got a strong reason not to.

CWE. Weakness category. The upstream advisory used CWE-346 (Origin Validation Error) and CWE-350 (Reliance on Reverse DNS Resolution). Same advice as CVSS: match upstream rather than reasoning from first principles.

Description. Markdown. I used Summary, Impact, Patches, Workarounds, References. The Workarounds section is the one I'd most strongly suggest including - if a user can't upgrade immediately, knowing how to mitigate is more useful than knowing the CVSS score. For dynoxide that was "use the stdio transport, don't pass --http."

The bug

The named CVE is DNS rebinding. You're running dynoxide mcp --http so your coding agent can talk to a local DynamoDB. You visit a malicious page in another tab. The page's JavaScript spoofs the Host header in requests to 127.0.0.1:PORT/mcp and the server processes them. The attacker can call any tool the running dynoxide instance exposes, including writes.

The rmcp 1.4+ fix is a Host-header allowlist: localhost, 127.0.0.1, ::1, anything else gets a 403. Upgrade rmcp, done.

While I was reading the patched rmcp source to make sure I understood what the upgrade actually changed, I clocked something. The Host check closes rebinding. It doesn't close cross-origin CSRF.

fetch('http://127.0.0.1:PORT/mcp', {
  mode: 'no-cors',
  method: 'POST',
  body: JSON.stringify({ /* call put_item */ })
})

The browser sends Host: 127.0.0.1 - legitimately, because that's the URL it's connecting to - and Origin: https://evil.com. The Host check passes. There's no Origin check by default. The request goes through.

A pedant's note: a no-cors POST with a JSON body actually can't set Content-Type: application/json (browsers strip it down to text/plain), so rmcp's protocol-level Accept and Content-Type checks would bounce this exact request before tool execution. The point still stands. Content-type validation isn't a security boundary - alternative request shapes that sidestep no-cors's restrictions (form POSTs, future MCP transport variants) reach the handler with valid framing. Origin is the right layer to enforce same-origin, not content-type.

This isn't a flaw in the upstream fix. The CVE is narrowly scoped to DNS rebinding, and the fix closes it. Cross-origin CSRF is a different shape of attack on the same transport surface, and the upstream rmcp team have it tracked as a defence-in-depth follow-up. rmcp 1.6.0 already ships an allowed_origins field on the same config - it just defaults to empty, which means "skip validation". Same pattern Host had before 1.4.

So dynoxide 0.9.13 sets both lists explicitly:

c.allowed_hosts = vec!["localhost".into(), "127.0.0.1".into(), "::1".into()];
c.allowed_origins = vec!["http://localhost".into(), "http://127.0.0.1".into()];

Plus a regression test covering all three paths: loopback Host with no Origin (passes, because native MCP clients don't send Origin), foreign Host (403), foreign Origin (403). The test asserts on the rejection message, not just the status code, so a future rmcp change that returns 403 for some other reason can't keep the test green while reopening the vulnerability.

What I'd tell past-me

The advisory is a positive signal. I was anxious about publishing it. Felt like it made dynoxide look amateur, like I was admitting fault. The opposite is true. Projects with zero advisories either have no users or aren't handling issues responsibly. Filing one is what well-run projects do.

Match the upstream CVSS and CWEs. Already covered above. The recalculation is defensible in theory but the consistent practice is simpler, faster, and less error-prone.

Turn on the email notifications. Worth the small ongoing noise on the repos you maintain.

One thing the whole exercise sharpened for me: the HTTP transport doesn't authenticate callers at all. The Host and Origin allowlists defend against browsers, but anything on the same machine that can reach the loopback port can call any tool. Worth saying why.

Why no auth (yet)

The MCP HTTP transport doesn't authenticate callers. That was a deliberate choice, not an oversight. dynoxide's main job is to be a small fast binary running in a CI job or on your own machine - both isolated environments where the only thing that can reach the loopback port is the process that launched it. The threat model is browser-borne attacks against that port, which is exactly what the Host and Origin allowlists handle. Adding token-based auth on top buys you very little: you'd be issuing yourself credentials to talk to yourself, and self-issued credentials tend to end up in dotfiles or pasted somewhere they shouldn't be.

What's changed the calculation is the Docker image I've been working on. A container is a different deployment shape: it's something you can hand to another developer, drop into a shared environment, or expose on a network where the caller isn't the process that launched it. The trust boundary widens and the assumptions behind shipping without auth stop holding.

So auth is the next piece of work. There's more design space here than I expected - the MCP spec is OAuth 2.1 or nothing, rmcp doesn't ship an auth hook of its own, and the path that actually fits a single-user local tool (a pre-shared bearer token wired in as a tower middleware) isn't really what the spec contemplates. More on that when it lands.

dynoxide 0.9.13 is out. Upgrade if you're running dynoxide mcp --http or dynoxide serve --mcp. The advisory is at GHSA-fvh2-gm75-j4j7 if you want a look at the finished form. If you've never filed a GHSA and you've got the option to file a draft on a private repo just to see the form, that's the cheapest way to take the unknown out of it before you have to do it for real.

Building a DynamoDB conformance suite

Martin Hicks — Mon, 13 Apr 2026 16:09:34 +0000

When I started building Dynoxide - a DynamoDB-compatible engine in Rust - I kept running into the same problem. I'd implement an operation, write tests against my understanding of DynamoDB's behaviour, and ship it. Then someone (usually me) would discover that real DynamoDB does something slightly different. A validation error with a different message. A condition expression that fails where I expected it to succeed. An edge case in number precision that I'd never considered.

Every emulator ships with "DynamoDB compatible" and you're expected to take their word for it. I needed a way to answer a simple question: does Dynoxide actually behave like DynamoDB?

No public conformance suite exists for DynamoDB - not from AWS, not from the community.

So I built one.

The idea

The principle is straightforward. Write a test. Run it against real DynamoDB. Record the result. That recorded result becomes the ground truth. Then run the same test against an emulator and compare.

If the emulator's response matches DynamoDB's, the test passes. If it doesn't, the emulator has a conformance gap. No opinions, no guesswork about what the documentation means - just "does this behave the same way the real thing does?"

I built it as a standalone project - dynamodb-conformance - so anyone can clone it, point it at their own DynamoDB-compatible endpoint, and get results. It uses the AWS SDK v3 for TypeScript and vitest as the test runner. Nothing exotic.

Tiers

Not all DynamoDB operations are equally important. If your emulator can't do a basic PutItem, nothing else matters. If it doesn't perfectly replicate the error message format for an obscure validation edge case, that's less critical.

So the suite is split into three tiers.

Tier 1 covers core CRUD operations - CreateTable, PutItem, GetItem, UpdateItem, DeleteItem, Query, Scan, BatchGetItem, BatchWriteItem. These are the operations every application uses. If an emulator fails here, it's not usable for real development.

Tier 2 covers advanced features - transactions, PartiQL, streams, tags, TTL, and table updates like billing mode changes. These are features that production applications rely on but that you might not hit in a simple prototype.

Tier 3 covers edge cases and error fidelity - validation ordering, exact error message formatting, API limits, and legacy API behaviour. The things that only matter when you need your emulator to be indistinguishable from the real service.

This tiered structure means a result like "100% Tier 1, 95% Tier 2, 80% Tier 3" actually tells you something useful. It means core operations work perfectly, advanced features are mostly there, and edge cases have some gaps. A flat "92% overall" hides whether the failures are in PutItem or in obscure validation corner cases.

Ground truth

The key design decision was making DynamoDB itself the source of truth rather than my interpretation of the documentation.

Every test in the suite has been run against a real DynamoDB table in eu-west-2. The expected values in the tests aren't what I think DynamoDB should return based on reading the docs - they're what DynamoDB actually returns. This matters more than you'd expect. DynamoDB's documentation is good, but it doesn't cover every edge case. Sometimes the only way to know what DynamoDB does is to try it and see.

A scheduled CI job runs the full suite against real DynamoDB weekly, so if AWS changes something - a new validation, a different error message, a behavioural tweak - the ground truth stays current. The suite can't go stale the way a set of hand-written expected values would.

Results

Here's where it gets interesting.

Target	Tier 1 (267)	Tier 2 (93)	Tier 3 (166)	Overall
DynamoDB (eu-west-2)	100%	100%	100%	526 / 526
Dynoxide	100%	100%	100%	526 / 526
LocalStack	98.9%	95.7%	81.9%	489 / 526
DynamoDB Local	98.9%	90.3%	81.9%	484 / 526
Dynalite	98.1%	10.8%	92.8%	426 / 526

Dynoxide passes every test. 526 out of 526, across all three tiers.

DynamoDB Local - AWS's own emulator - fails 42. LocalStack fails 37. Dynalite, which hasn't been actively maintained for a while, fails 57 (and that Tier 2 number of 10.8% tells you it's missing entire feature categories like transactions and PartiQL).

I want to be careful about what this means and what it doesn't.

526 tests is a lot, but DynamoDB is a massive service. There are aspects of it that the suite doesn't cover - DAX compatibility, on-demand capacity semantics, cross-region replication, fine-grained IAM condition keys. "100% conformance on 526 tests" is accurate. "100% DynamoDB compatible" is not, and I wouldn't claim it.

What the results do tell you is that for the operations and behaviours the suite covers - which include everything most applications use day to day - Dynoxide matches DynamoDB exactly. Not approximately. Exactly.

What DynamoDB Local gets wrong

Some of DynamoDB Local's 42 failures are genuinely surprising. This is AWS's own emulator. You'd expect it to be the gold standard for local DynamoDB development. In practice, it has real gaps across all three tiers.

Three of its Tier 1 failures are in ItemCollectionMetrics - it doesn't return them for PutItem, DeleteItem, or UpdateItem even when you ask for them with ReturnItemCollectionMetrics: SIZE. That's not an edge case. That's a documented feature of the API that silently does nothing.

In Tier 2, the entire tagging API is broken. All eight tag-related tests fail - TagResource, UntagResource, ListTagsOfResource. If you're writing infrastructure-as-code that tags tables and you're testing against DynamoDB Local, none of that is being validated. It also gets PartiQL INSERT semantics wrong - it treats INSERT as an upsert when real DynamoDB correctly rejects an INSERT on an existing item.

The bulk of the failures (30) are in Tier 3 - validation ordering and error message formatting. DynamoDB Local returns different errors than production for the same bad request. This might sound academic, but if you're writing error handling code against DynamoDB Local, it might not work the same way against the real thing. You'll get the right error type but the wrong message content, or the validations will fire in a different order.

These are the kind of differences you only discover when you have a conformance suite to catch them. Without one, they hide as production bugs that are impossible to reproduce locally.

Why bother?

I built this because I needed it for Dynoxide. I wanted confidence that the thing I was building actually worked the way DynamoDB works, not the way I assumed it works. But the suite is useful beyond that.

If you're choosing between DynamoDB emulators for your development workflow, you can run the suite yourself and compare. The numbers above aren't marketing claims - they're reproducible results from a public repository that anyone can verify.

If you maintain a DynamoDB emulator or compatibility layer, you can use it to find and fix gaps. Point it at your endpoint, see what fails, fix the failures. The tiered structure tells you which failures matter most.

And if you're using DynamoDB Local in your CI pipeline and wondering why a test passes locally but fails against real DynamoDB - the conformance suite might tell you why. The 42 things DynamoDB Local gets wrong are 42 potential sources of exactly that kind of bug.

526 tests is solid coverage, but there are DynamoDB behaviours the suite doesn't exercise yet. If you've hit a case where an emulator diverges from real DynamoDB and you think it should be covered, open a PR. The only requirement is that the test passes against real DynamoDB - include the results artifact from a run against your own AWS account and I'll verify it against the ground truth pipeline. More tests make the suite more useful for everyone, not just Dynoxide.

The suite is at github.com/nubo-db/dynamodb-conformance. Clone it, run it, check the results for yourself.

Introducing Dynoxide: a fast, embeddable DynamoDB engine

Martin Hicks — Thu, 02 Apr 2026 21:02:51 +0000

I've been working with DynamoDB for the best part of a decade. It's my default database for most things I build at Si Novi, and I genuinely like it. The data modelling is satisfying once it clicks, the operational overhead is basically zero, and it scales without you having to think about it.

Last year, Si Novi started building Nubo, a native DynamoDB client for macOS and iPadOS, with Windows and Linux on the way. One of the features we wanted from the start was a built-in sandbox. A local DynamoDB instance running on-device that you could experiment with, no AWS credentials needed. Create tables, insert data, test access patterns. All offline. All on your machine. Maybe even on an iPad.

The problem was: how do you ship that?

DynamoDB Local's licence explicitly prohibits redistribution. You can't bundle it inside another application or sublicence it. Even setting the licence aside, the developer experience would have been awful. Asking users to separately download and install a Java-based emulator, with Docker or a JVM as a prerequisite, just to use one feature in your app? That's not a sandbox. That's homework.

And on iPadOS there's no path at all. No JVM. No Docker. Nothing.

So I started building something new. A DynamoDB-compatible engine in Rust, backed by SQLite, that compiles to a single native binary. Something I could embed directly into Nubo as a library.

That's how Dynoxide started.

From library to tool

The first version did exactly what I needed: a local DynamoDB that Nubo could bundle as its sandbox. Job done, in theory. But the thing that surprised me was just how small and fast it turned out to be.

A ~3 MB download (~6 MB on disk). Under 5 MB of RAM at idle. Cold startup in about 15 milliseconds, compared to over two seconds for DynamoDB Local. Numbers like that change what's practical. Instead of running one shared DynamoDB instance in your CI pipeline, you could spin up a fresh one per test. Isolated state. No cleanup step. No flaky tests from leftover data. Tear it down when you're done and the overhead is essentially nothing.

That realisation shifted what Dynoxide was becoming. It wasn't just infrastructure for Nubo any more. It was a tool in its own right.

The same properties that made it good for CI made it a natural fit for agentic development. A coding agent that needs to create tables, write data, or test queries can do all of that through Dynoxide's built-in MCP server. 34 tools, no setup required. Run dynoxide mcp and your agent has a full DynamoDB environment to work with.

And then I looked at how many Node.js projects still depend on dynalite for local DynamoDB. I owe a lot to dynalite. Using it through arc.codes and Architect is what turned DynamoDB from a database I'd reach for occasionally into the one I'd reach for first. Having a fast local emulator that just worked changed how I thought about building with DynamoDB. It made the feedback loop tight enough that I actually wanted to experiment. But dynalite hasn't seen updates in a while and newer DynamoDB features like transactions and streams aren't covered. Dynoxide supports both, along with the rest of the API surface. With an npm package shipping platform-specific binaries (the same approach esbuild and Biome use), it works as a drop-in replacement. Same workflow, one line change in your package.json.

Under the hood

Dynoxide implements the DynamoDB API as a translation layer in Rust, storing data in SQLite and compiling to a native binary with no runtime dependencies. DynamoDB Local takes the same general approach (SQLite as the storage engine is well documented) but ships as a Java application with a JVM dependency and a restrictive licence.

Because SQLite is an embedded database, Dynoxide doesn't have to run as a standalone server. It can be linked directly into another application, which is exactly how Nubo uses it. Encrypt the database file with SQLCipher and you've got a portable, encrypted, DynamoDB-compatible data store. Nubo uses this for its local cache: data you've previously accessed from AWS is kept in an encrypted database on-device, so it loads instantly and works offline.

To make sure Dynoxide actually behaves like the real thing, I built a conformance test suite. 526 tests, all validated against real DynamoDB on AWS. Every emulator gets the same suite. Dynoxide passes all 526. DynamoDB Local manages 92%. LocalStack gets 93%. Dynalite hits 81%.

The suite is public. Anyone can run it and verify.

Get started

Homebrew:

brew install nubo-db/tap/dynoxide

npm (drop-in dynalite replacement):

npm install --save-dev dynoxide

Cargo:

cargo install dynoxide-rs

Then just run it:

dynoxide

Full documentation is at dynoxide.dev, and the source is on GitHub.

Dynoxide is the foundation. But the thing I'm building on top of it is what I really want to talk about next. Nubo is a native DynamoDB client for macOS and iPadOS, and I think people who work with DynamoDB day to day will love it. If that sounds interesting, there's a mailing list at nubo.sinovi.uk.

Dynoxide stands on its own though. If you're running DynamoDB Local in CI and wondering why your pipeline is slow, or you're still using dynalite and need coverage for newer API features like transactions and streams, give it a try. I'd love to know what you think.

Si Novi will be at AWS Summit London on April 22nd. If you're there and want to talk DynamoDB, come and find me.