Could namastack be used in multi-tenancy scenarios with multiple datasources?

[jjank]

Hi there!

thanks for creating namastack - it looks very promising and we are strongly considering it for an upcoming project!

The project however has to handle multitenancy with both a tenant-id in the entities and multiple datasources. We cannot change this unfortunately. Also we have to use JPA (Hibernate to be specific) because there's company-internal libraries that give us some abstraction (basically an implementation of AbstractRoutingDatasource)

There are 2 questions that unfold from there regarding namastack:

1. Regarding the tenant-id attribute: Considering this hibernate forum answer it could be possbile to set up a custom orm.xml and configure/modify the entities in namastack-jpa such that an additional column annotated with @TenantId is respected.
2. This seems more difficult: Could we extend/configure namastack such that the scheduled processing of outbox records would (for lack of a better word) "span" across all available datasources? From my understanding we'd need a collection of N OutboxProcessingScheduler instances that are assigned to the N available Datasources. Or is that something that a custom implementation of OutboxRecordRepository could/should do?

Thanks for your thoughts!

[rolandbeisel]

Hi, thanks a lot for the detailed context and for considering Namastack!

Great questions. Short answer for both points: this is currently not supported out of the box, but we do see this on our roadmap.

1. Tenant-id on JPA entities (@TenantId / ORM customization): At the moment, namastack-outbox-jpa uses a fixed OutboxRecordEntity mapping and does not provide built-in tenant-column multitenancy support (for example, a native @TenantId field in the shipped entity model).

2. Scheduled processing across multiple datasources: Your understanding is correct: the current core wiring creates one OutboxProcessingScheduler that uses one injected OutboxRecordRepository, so there is no built-in "span all datasources automatically" mode today.

Thanks again for raising this - this is valuable input for prioritization.

[jjank]

Thanks for the quick reply and for considering this 👍

I'll throw in one more level of (possible) difficulty here: The tenantId may have to be part of a composite primary key in our system. I'm not 100% sure about this yet.

This kinda raises the question where you'd want to draw a line between configurable/flexible and opinionated with regards to the design of the JPA entities shiped with namastack.

EDIT: Ok, after doing some research: I wasn't aware how much one can override with an orm.xml file... 😅

[rolandbeisel]

@jjank I’m not convinced that the tenantId should be stored in the outbox table (as column) at all. If the outbox handler needs access to the tenantId, it could instead be passed through the OutboxRecordContext.

From my perspective, there are two separate questions to consider:

1. How should tenant information be propagated in a shared schema?
   This could be handled via the OutboxRecordContext.

2. How can multiple data sources be supported?
   This would require a more substantial change to Namastack Outbox.

[Ekto-Nova]

Hi @rolandbeisel . I'm also considering using Namastack for one of my projects — it looks truly promising, and the amount of work and thought you've put into it is amazing. I wanted to check in on the multi-tenancy topic:

1. Is native support for multiple datasources (one per tenant) still something you're considering as part of the roadmap? If so, are there any defined dates or plans for it?
2. If it does get implemented, is the intent to keep it fully opt-in and backward compatible for existing single-tenant users — e.g. behind a property or a separate module — rather than changing the current bean wiring?

Happy to be part of the discussion. Thanks!

[rolandbeisel]

Hi @Ekto-Nova,

Thanks for the interest and for the thoughtful questions!

Yes, support for multiple datasources / tenants is something I'm actively working on.

The current direction goes beyond simply wiring multiple datasources into a single outbox runtime. Instead, I'm building a multi-channel architecture where each channel has its own isolated outbox runtime, including its own scheduler, handler registry, retry registry, partition ownership, repository infrastructure and persistence configuration.

One of the main design goals is to keep existing applications fully backward compatible. Single-datasource users should not have to change their configuration or bean wiring. Multi-channel support is being designed as an explicit opt-in capability rather than changing the default runtime model.

I already have an early internal implementation and I'm currently looking for a small number of users willing to validate the design with real-world use cases before the first public preview becomes available.

@Ekto-Nova @jjank If you're interested in participating, feel free to reach out at hello@namastack.io. I'd be particularly interested in learning more about:

• your tenant model
• datasource setup
• expected tenant count
• database technologies involved
• operational requirements

Real-world feedback is extremely valuable at this stage and helps ensure the final design solves actual production use cases.

Thanks for joining the discussion!