Spring Data DynamoDb

[MatejNedic]

I have already started but would like to hear ideas, opinnions and discussion how you use it. This will greatly help in releasing RC.
It will primary usecase be single table design and wont implement it in any other way.

[AldinDuraki]

What exactly do you mean by the single table design? Is this really only supporting a single table with all entities being in that table?

[MatejNedic]

Exactly all entites in one table (including global indexes support). Dont plan to support rational model where you would invoke 2 api requests to 2 different tables. It is anti pattern.

Meaning 1 table multiple entites different structure you need to know what to query and it will be serialized to your objects. Already have working examples where there is 1 partition key holding multiple entites and you can with 1 query get many of them serialized to proper types.

[AldinDuraki]

That's good, the more support for spring there is the better!

I don't want to change the discussion topic, but it is not a anti pattern. These are just two different database designs. Having a own table for each entity has benefits so has the single table design. One for example is, that you can grant read access to different aws accounts limited to entities without going the extra mile of e.g. Lake Formation. But yea - feel free to implement the single table design and when it is mature enough we might discuss the other design 😄

[RyanVerWey]

It’s an interesting direction, and I’m on board with single-table as the default. This will land if the common patterns feel effortless: clear PK/SK conventions with friendly helpers for starts-with and range queries (so we avoid scans), simple LEK-based pagination, and explicit access to named GSIs, including sparse ones, with projections to keep reads cheap. Solid conditional writes for idempotency and optimistic locking, plus partial updates, cover most write paths. Add lightweight polymorphism/type tags for mixed entities, built-in converters for nested/JSON fields, and a plug-and-play test setup with LocalStack or Testcontainers. If RC ships with a few opinionated examples (time-series, ownership lists, GSI fan-out) and guidance on when not to force a single table, I think you and your team can adopt it with confidence. Good luck with the project!