Thanks for the summary, Prashant!
I believe 1 DataSource (database) per realm _is_ possible with current
code, but it also implies one JVM per realm (just to clarify the last
paragraph in your message).
Given that the need for strong realm isolation at the database level is
likely to co-exist wit
It was unfortunate Quarkus doesn't provide the capability to configure
multiple data sources without recompilation. It left us no choice but to
use a custom data source manager. It doesn't seem urgent to me though. I'm
fine with the current strategy until there are strong use cases demanding a
sepa
Hey folks,
Apologies for the delay, I wanted to bring up one issue which we faced
during the implementation of 1 JVM supporting multiple realms essentially
1 DS per realm which to be injected via quarkus props i.e
https://github.com/apache/polaris/pull/1482 and using quarkus managed DS
and seek p
To clarify, Polaris *does* support multi-tenancy. What’s currently limited
with Option 1 is *account-level* multi-tenancy specifically in the context
of EclipseLink.
1. *Multi-account support* is most relevant when a vendor wants to
commercialize Polaris and offer it as a service to customer
Hi all,
I also would like to reiterate that Quarkus has no particular support for
multi-tenancy with options 1 or 2: unless there are only a handful of
datasources to use, and they can all be fixed at build time (which I think
is not the case here), we'd need to manage the datasources and their
co
My point is that if we do not include realm ID in the Primary Key (option
1), then we're effectively forcing all users to deploy Polaris with a
DataSource per Realm approach. I do not see how we can decouple this
concern from the JDBC schema. Any subsequent schema changes will complicate
upgrades.
Hey All,
Based on our recent discussion and the PR feedback, it seems like we need
more in-depth conversations to align on the best path forward.
Considering this, I'd like to propose we decouple this particular feature
from the current JDBC implementation.
My reasoning for this suggestion is as
Thanks for the thoughtful input.
While it's true that some environments may not require strict separation
between realms, the risk of incorrect usage or subtle cross-realm
interference is significantly higher if we allow shared databases without
enforcing strong boundaries.
Option 1 gives us stro
I believe users of Apache Polaris may want to share the database across
many realms in environments that do not need secure separation of realms.
This is hypothetical, at this point, of course. However, If option 3 is not
supported by code that use case will be impossible (or require subsequent
cha
Hi Folks,
As we discussed, option 1 provides the strongest isolation, which should
work particularly well for dynamically created data sources. Another
significant benefit is that it's less complicated overall.
I'm not convinced we need both option 1 and option 3. For scenarios
involving only a s
Going with options 1 and 3 initially sounds good to me. This should
simplify current JDBC PRs too.
We can certainly add capabilities later, because having realm ID in the PR
does not preclude other deployment choices.
Cheers,
Dmitri.
On Tue, Apr 15, 2025 at 1:49 PM Michael Collado
wrote:
> My
My $.02 is that Option 1 is entirely possible using a DataSource that
dynamically creates Connections as needed. Option 1 is nice because, as
Pierre said, it gives admins the ability to dynamically allocate resources
to different clients as needed.
Personally, I'm less inclined to option 3 just be
Hi all,
I'm in agreement with Pierre, JB and Dmitri's points. I’d like to add some
context from the Quarkus configuration angle:
Option 1, which involves distinct datasources, presents a challenge.
Quarkus requires all datasources to be present and fully configured at
build time. This requirement
Hi folks,
The three approaches should be transparent for end users.
According to the isolation that a realm is supposed to guarantee, I
think we should consider 1 and 2 (3 is maybe too light in terms of
strong isolation).
1 and 2 can be achieved by configuration: it could be a dedicated
database,
Thanks for your perspective, Pierre! You make good points and I agree with
them.
>From my POV, I'd add that we probably need to take deployment concerns into
account too.
If the deployment uses the database per realm approach (option 1) then
someone has to provide database connection parameters (
Hi Prashant
I guess the answer will depend on how easy it should be for Polaris to
support multi-tenancy.
A separate database per realm would allow administrators to limit the
amount of resources that a realm can consume (e.g. the maximum number of
database connections). Indeed, it would be one
16 matches
Mail list logo
