Introduce DataSourceResolver for multi-datasource support in JDBC per… by Subham-KRLX · Pull Request #3960 · apache/polaris

Subham-KRLX · 2026-03-09T18:31:30Z

Introduces a DataSourceResolver interface to decouple DataSource selection from JdbcMetaStoreManagerFactory, enabling per-realm and per-store-type routing (main, metrics, events).

Changes:

New DataSourceResolver interface with resolve(realmId, storeType)
DefaultDataSourceResolver — routes everything to the default DS (no behavior change)
JdbcMetaStoreManagerFactory now uses DataSourceResolver instead of direct Instance<DataSource>

This is the foundation for #3890. Named DS resolution and config properties will follow.

Closes #3890

Checklist

🛡️ Don't disclose security issues!
🔗 Linked: Fixes Support multiple data sources in JDBC persistence #3890
🧪 Tests to be added in follow-up
💡 Added comments for complex logic

dimas-b · 2026-03-09T18:33:44Z

@Subham-KRLX : thanks for the proposal... I'll review presently, but please fix conflicts to allow CI to run.

…sistence This commit introduces the DataSourceResolver interface and a DefaultDataSourceResolver implementation to enable flexible routing of DataSources based on realm and store type (e.g., main, metrics, events). Key changes: - New DataSourceResolver interface with resolve(realmId, storeType) and getAllUniqueDataSources() methods - DefaultDataSourceResolver that routes all requests to the default DataSource (backward-compatible no-op) - Refactored JdbcMetaStoreManagerFactory to use DataSourceResolver instead of direct DataSource injection This lays the groundwork for isolating different persistence workloads (entity metadata vs metrics vs events) into separate connection pools or databases to mitigate noisy neighbor effects. Closes apache#3890

dimas-b

Very nice idea, @Subham-KRLX ! +1 to this approach in general.

Posting quite a few comments, but they are just to "streamline" the code (I hope).

- Refactored StoreType to an enum in DataSourceResolver - Removed getAllUniqueDataSources() from DataSourceResolver (Admin use case) - Moved DefaultDataSourceResolver to runtime/common/config/jdbc - Inject plain DataSource instead of Instance<DataSource> in DefaultDataSourceResolver - Updated JdbcMetaStoreManagerFactory to use the new StoreType enum

Subham-KRLX · 2026-03-09T18:59:05Z

@dimas-b thanks for the review I have streamlined the implementation based on your feedback by refactoring StoreType into an enum within DataSourceResolver and removing the getAllUniqueDataSources() method to keep the interface focused strictly on runtime resolution. Additionally I moved DefaultDataSourceResolver
to the runtime-common module to better decouple the persistence layer from resolution logic and simplified the implementation by injecting a plain DataSource instead of an Instance.

dimas-b

A couple more comments, but LGTM overall 👍

@Subham-KRLX : Do you want to remove the "draft" status and open this for general review?

I'd suggest to also send an email about this to dev for visibility.

@Inject

- Renamed StoreType.MAIN to METASTORE - Use RealmContext instead of String realmId in DataSourceResolver.resolve - Added missing polaris-core dependency to runtime-common - Fixed formatting of @Inject fields for Spotless

dimas-b · 2026-03-09T19:15:21Z

+   * @return the resolved DataSource
+   */
+  DataSource resolve(
+      org.apache.polaris.core.context.RealmContext realmContext, StoreType storeType);


nit: import

@dimas-b I have pushed an update to resolve the CI failures. It turned out to be a CDI injection issue with the @Identifier annotation that I have now resolved.

Subham-KRLX · 2026-03-09T19:22:20Z

Thanks for the approval @dimas-b. I have fixed that last import nit and have sent the proposal email to the dev list [1] for broader visibility as you suggested. Appreciate all the guidance on streamlining this.

dimas-b · 2026-03-10T14:32:52Z

@Subham-KRLX : the PR LGTM, but please check CI failures out 😅

…solution

Subham-KRLX · 2026-03-11T07:34:55Z

@dimas-b @flyrain I’ve pushed an update to fix the CI failures in the non-JDBC test suites. The root cause was DefaultDataSourceResolver unconditionally injecting a JDBC DataSource bean, which caused an io.quarkus.arc.InactiveBeanException when booting profiles where JDBC is disabled (like NoSQL/Mongo). I’ve updated the implementation to use Instance for lazy resolution, allowing the service to boot safely across all persistence modes. All CI checks should now pass cleanly.

dimas-b · 2026-03-11T17:26:41Z

[...] The root cause was DefaultDataSourceResolver unconditionally injecting a JDBC DataSource bean, which caused an io.quarkus.arc.InactiveBeanException when booting profiles where JDBC is disabled (like NoSQL/Mongo).

Current code in this PR LGTM, however, I still wonder why would DefaultDataSourceResolver be "engaged" in non-JDBC contexts (and subsequently get the InactiveBeanException) 🤔

@Subham-KRLX : Could you explore this a bit more?

Perhaps DefaultDataSourceResolver may need to be a @Dependent bean rather than @ApplicationScoped 🤔

flyrain · 2026-03-11T18:43:05Z

As I said in the mailing thread https://lists.apache.org/thread/nokyythvrdzsfwz26hx0w5rpxrw5wjtd, I think this effort deserve more thoughts before we start coding. cc @singhpk234

…ultBean

Subham-KRLX · 2026-03-12T11:18:32Z

[...] The root cause was DefaultDataSourceResolver unconditionally injecting a JDBC DataSource bean, which caused an io.quarkus.arc.InactiveBeanException when booting profiles where JDBC is disabled (like NoSQL/Mongo).

Current code in this PR LGTM, however, I still wonder why would DefaultDataSourceResolver be "engaged" in non-JDBC contexts (and subsequently get the InactiveBeanException) 🤔

@Subham-KRLX : Could you explore this a bit more?

Perhaps DefaultDataSourceResolver may need to be a @Dependent bean rather than @ApplicationScoped 🤔

Hi @dimas-b the root issue is Quarkus ArC's eager boot-time validation.Since DefaultDataSourceResolver
is in runtime-common, it’s always discovered during boot (even in NoSQL profiles). The Quarkus JDBC extension disables the DataSource bean when JDBC is off.
A direct @Inject DataSource causes Quarkus to throw an InactiveBeanException immediately at boot because the required injection point cannot be satisfied. By using @Inject Instance, we make the injection point dynamic/lazy, bypassing the strict upfront validation. (Even if the bean were @dependent, Quarkus ArC still eagerly validates all discovered injection points by default).

flyingImer

Thanks. I’m aligned with keeping this extensible, and I agree workload isolation is a useful direction.

My main concern is that the current PR may already be standardizing a broader routing contract than the implementation actually justifies today.

IIUC the current behavior is still quite narrow:

• the default resolver does not yet differentiate meaningfully by RealmContext / StoreType,
• the tests mostly validate the refactoring shape rather than the SPI as a real extension contract,
• and the current split still looks closer to logical separation than a clearly-defined built-in routing model.

So I wonder if we should be more explicit about the narrower initial story this PR is trying to support.

If the immediate goal is workload isolation, I’d rather scope this PR around that foundation first, and leave broader realm-aware routing as a later / separately justified step.

My concern is mostly about not letting “SPI can support this later” implicitly turn into “Polaris v1.x now owns this broader built-in routing story” before that boundary is explicit.

…CDI producers to runtime-common

…sistence (apache#3960) Drafted design doc, fixed purge for isolated stores, and resolved build failures.

Subham-KRLX · 2026-04-01T09:58:07Z

@flyrain, @flyingImer, @dimas-b Just wanted to let you know that I have updated the PR with the fixes we discussed and have officially sent the design proposal for Multi-DataSource support to the dev@polaris.apache.org mailing list for broader community feedback You can find the design document in the repository here: jdbc-multi-datasource.md

dimas-b

Concentrating on the proposal doc for now.

dimas-b · 2026-04-01T18:14:50Z

+  ~ specific language governing permissions and limitations
+  ~ under the License.
+  -->
+# Design: Multi-DataSource support in JDBC persistence


Should this perhaps be under unreleased/proposals?.. e.g. like in this proposal using GH PR and .md files: #3924

I personally do not mind having the proposal doc in the same PR as the implementation, but we need to be careful with reviews so as to settle on the general proposal first and proceed to code changes later (to avoid unnecessary work).

dimas-b · 2026-04-01T18:16:10Z

+
+### Bootstrap
+When a realm is bootstrapped via `JdbcMetaStoreManagerFactory.bootstrapRealms()`:
+1.  **Resolution**: The `DataSourceResolver` is called for each `StoreType` (METASTORE, METRICS, EVENTS).


I'd think the bootstrap process should indicate which of the possible store types to initialize. Ultimately this is a the Admin user's decision, I think (defaulting to all).

The rationale is to not create tables that the Admin user knows are not going to be used (reducing database maintenance burden by not creating "dead" tables).

dimas-b · 2026-04-01T18:17:33Z

+Upgrading a Polaris deployment from version N to N+1 involves:
+1.  **Detection**: The service detects that the `metastore`'s `polaris_schema_version` is below the requested level.
+2.  **Execution**: The migration logic resolves each `StoreType` and applies the relevant "vN-to-vN+1" upgrade script.
+3.  **Consistency**: Because the process is unified within the `JdbcMetaStoreManagerFactory`, it provides a single point of failure and ensures that all data sources are either upgraded or rolled back (where possible).


Different store types do not have to be on the same schema version, IMHO. Their tables are not transactionally related.

Moreover, storage for METRICS does not have to be JDBC even if METASTORE is JDBC (same for events).

dimas-b · 2026-04-01T18:20:27Z

+## Schema Upgrades
+Upgrading a Polaris deployment from version N to N+1 involves:
+1.  **Detection**: The service detects that the `metastore`'s `polaris_schema_version` is below the requested level.
+2.  **Execution**: The migration logic resolves each `StoreType` and applies the relevant "vN-to-vN+1" upgrade script.


I believe schema upgrades should be part of the bootstrap flow and require an explicit user action... WDYT?

I have refactored the Multi-DataSource JDBC implementation to fully address the feedback from @dimas-b. This update introduces selective bootstrap control via new CLI flags (--metastore, --metrics, --events), independent schema versioning for each store type, and moves schema upgrades to the explicit administrative bootstrap flow Additionally I have added null-safety to JdbcBasePersistenceImpl to support heterogeneous storage for metrics and events, and the design proposal has been finalized and moved to site/content/in-dev/unreleased/proposals/jdbc-multi-datasource.md.

Thanks, @Subham-KRLX !

@flyrain , @singhpk234 : What is your take on the proposed design?

…sioning, and heterogeneous storage support

dimas-b · 2026-04-07T19:28:05Z

@flyrain @singhpk234 : please review the latest changes proposed by @Subham-KRLX .

From my POV, the PR is moving in the right direction, but I'd appreciate reviews from both of you before we proceed. Thx!

github-actions · 2026-05-17T02:17:08Z

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

… of **runtime** activation of the desired datasource. This is achieved by: 1) Introducing a new enabler property: `polaris.persistence.relational.jdbc.datasource`, which points to a named datasource to activate. 2) Declaring, **at build time**, one named datasource for each JDBC driver shipped with the application. 3) Introducing a new `DataSourceActivator` config interceptor that will, at runtime, change the `active` setting of the target datasource to `true`, and all others to `false` (`active` is a runtime setting, contrary to `db-kind`). This change also makes the server ship with the H2 driver by default, since that's the pre-condition for an H2 datasource to be selected at runtime. This change will further enable **as future improvements**: - Using to JDBC + H2 by default for server images, while still allowing users to switch to PostgreSQL *without having to rebuild Polaris*. - Enabling the persistence to "plug" into not one, but many datasources, e.g. a specific datasource for main persistence, and a separate datasource for metrics. This was outlined in apache#3960 – but the machinery to make that happen was missing.

This change enables multiple datasources in Polaris, with possibility of **runtime** activation of the desired datasource. This is achieved by: 1) Introducing a new enabler property: `polaris.persistence.relational.jdbc.datasource`, which points to a named datasource to activate. 2) Declaring, **at build time**, one named datasource for each JDBC driver shipped with the application. 3) Introducing a new `DataSourceActivator` config interceptor that will, at runtime, change the `active` setting of the target datasource to `true`, and all others to `false` (`active` is a runtime setting, contrary to `db-kind`). This change also makes the server ship with the H2 driver by default, since that's the pre-condition for an H2 datasource to be selected at runtime. This change will further enable **as future improvements**: - Using to JDBC + H2 by default for server images, while still allowing users to switch to PostgreSQL *without having to rebuild Polaris*. - Enabling the persistence to "plug" into not one, but many datasources, e.g. a specific datasource for main persistence, and a separate datasource for metrics. This was outlined in apache#3960 – but the machinery to make that happen was missing.

adutra · 2026-06-17T20:52:47Z

FYI relevant ML discussion:

https://lists.apache.org/thread/jy6wb186h94n9q86kv01shbn68ppr6gv

Relevant work:

#4812

Subham-KRLX · 2026-06-18T02:50:59Z

Thanks a lot @adutra for picking this up and continuing the multi-datasource work #3960 was closed by the stale bot but the design direction was still being actively discussed. I am happy to help carry this forward and align the earlier notes with #4812.

adutra · 2026-06-18T15:42:06Z

Thank you @Subham-KRLX ! Unfortunately the branch has been deleted and this PR cannot be reopened.

Let's wait to see if #4812 reaches consensus. If so, then I have some ideas about how to adapt your work on top of it. It shouldn't be hard.

This change enables multiple datasources in Polaris, with possibility of **runtime** activation of the desired datasource. This is achieved by: 1) Introducing a new enabler property: `polaris.persistence.relational.jdbc.datasource`, which points to a named datasource to activate. 2) Declaring, **at build time**, one named datasource for each JDBC driver shipped with the application. 3) Introducing a new `DataSourceActivator` config interceptor that will, at runtime, change the `active` setting of the target datasource to `true`, and all others to `false` (`active` is a runtime setting, contrary to `db-kind`). This change also makes the server ship with the H2 driver by default, since that's the pre-condition for an H2 datasource to be selected at runtime. This change will further enable **as future improvements**: - Using to JDBC + H2 by default for server images, while still allowing users to switch to PostgreSQL *without having to rebuild Polaris*. - Enabling the persistence to "plug" into not one, but many datasources, e.g. a specific datasource for main persistence, and a separate datasource for metrics. This was outlined in apache#3960 – but the machinery to make that happen was missing.

github-project-automation Bot added this to Basic Kanban Board Mar 9, 2026

github-project-automation Bot moved this to PRs In Progress in Basic Kanban Board Mar 9, 2026

Subham-KRLX marked this pull request as draft March 9, 2026 18:31

Subham-KRLX force-pushed the feat/multi-datasource-support branch from c082f09 to 136e381 Compare March 9, 2026 18:38

dimas-b reviewed Mar 9, 2026

View reviewed changes

Subham-KRLX marked this pull request as ready for review March 9, 2026 19:07

Final review nits on DataSourceResolver PR

e024bea

- Renamed StoreType.MAIN to METASTORE - Use RealmContext instead of String realmId in DataSourceResolver.resolve - Added missing polaris-core dependency to runtime-common - Fixed formatting of @Inject fields for Spotless

dimas-b reviewed Mar 9, 2026

View reviewed changes

Address final nit: use import for RealmContext

96e7ff0

dimas-b previously approved these changes Mar 9, 2026

View reviewed changes

github-project-automation Bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Mar 9, 2026

flyrain reviewed Mar 9, 2026

View reviewed changes

Comment thread ...al-jdbc/src/main/java/org/apache/polaris/persistence/relational/jdbc/DataSourceResolver.java

Final formatting and naming consistency cleanup

9a07e6e

Subham-KRLX dismissed dimas-b’s stale review via 9a07e6e March 10, 2026 03:39

Fix InactiveBeanException in non-JDBC profiles via lazy DataSource re…

75e4096

…solution

dimas-b previously approved these changes Mar 11, 2026

View reviewed changes

flyingImer reviewed Mar 12, 2026

View reviewed changes

Address review comments: tighten scope, use plain injection and @Defa…

fccb254

…ultBean

Subham-KRLX dismissed dimas-b’s stale review via fccb254 March 12, 2026 11:13

flyingImer reviewed Mar 31, 2026

View reviewed changes

Subham-KRLX added 2 commits March 31, 2026 10:56

Finalize PR apache#3960: split v4 DDL, fix license headers, and move …

7eb2304

…CDI producers to runtime-common

Introduce DataSourceResolver for multi-datasource support in JDBC per…

7ceaa69

…sistence (apache#3960) Drafted design doc, fixed purge for isolated stores, and resolved build failures.

dimas-b mentioned this pull request Apr 1, 2026

JDBC: Replace coarse-grained synchronized methods with per-realm locking #4054

Merged

6 tasks

dimas-b reviewed Apr 1, 2026

View reviewed changes

Refine Multi-DataSource support: selective bootstrap, independent ver…

9df42be

…sioning, and heterogeneous storage support

Subham-KRLX requested a review from dimas-b April 7, 2026 08:23

dimas-b requested review from flyrain and singhpk234 April 7, 2026 19:28

Subham-KRLX requested review from adutra and flyingImer April 13, 2026 02:42

github-actions Bot added the stale label May 17, 2026

github-actions Bot closed this May 24, 2026

github-project-automation Bot moved this from Ready to merge to Done in Basic Kanban Board May 24, 2026

Subham-KRLX deleted the feat/multi-datasource-support branch May 29, 2026 08:57

adutra mentioned this pull request Jun 17, 2026

Introduce multiple datasources #4812

Open

6 tasks

Subham-KRLX restored the feat/multi-datasource-support branch June 18, 2026 17:41

Uh oh!

Conversation

Subham-KRLX commented Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

dimas-b commented Mar 9, 2026

Uh oh!

dimas-b left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Subham-KRLX commented Mar 9, 2026

Uh oh!

dimas-b left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Subham-KRLX commented Mar 9, 2026

Uh oh!

Uh oh!

dimas-b commented Mar 10, 2026

Uh oh!

Subham-KRLX commented Mar 11, 2026

Uh oh!

dimas-b commented Mar 11, 2026

Uh oh!

flyrain commented Mar 11, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Subham-KRLX commented Mar 12, 2026

Uh oh!

flyingImer left a comment

Choose a reason for hiding this comment

Uh oh!

Subham-KRLX commented Apr 1, 2026

Uh oh!

dimas-b left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dimas-b commented Apr 7, 2026

Uh oh!

github-actions Bot commented May 17, 2026

Uh oh!

adutra commented Jun 17, 2026

Uh oh!

Subham-KRLX commented Jun 18, 2026

Uh oh!

adutra commented Jun 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Subham-KRLX commented Mar 9, 2026 •

edited

Loading