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
separated data source per realm.


Yufei


On Tue, May 13, 2025 at 10:29 AM Prashant Singh
<prashant.si...@snowflake.com.invalid> wrote:

> 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 probable path here.
>
> Initially we thought it could be possible with named custom data sources
> which turns out has some very rough edges, for ex: we need to specify at
> least one property during build time when using these custom DS (docs :
> https://quarkus.io/guides/datasource#configure-multiple-datasources) ref
> thread (https://github.com/apache/polaris/pull/1482#discussion_r2069548146
> )
> This kind of then puts a dependency on the users to rebuild the jar and
> makes the binaries not usable if we want to use named DS managed by
> Quarkus. Due to this, if we want to support this feature we will have to
> re-implement our own custom DS and manage its life cycle, at the same time
> moving away from quarkus.
>
> Re bumping this thread to know what you all think of ? Should we go and
> reimplement the custom DS to support 1 DS per realm ? or are we fine with
> the current strategy considering we can have 1 JVM routed to 1 realm still
> and then we can diff instance running diff realms ?
>
> Best,
> Prashant Singh
>
>
>
>
> On Tue, Apr 22, 2025 at 9:29 AM Yufei Gu <flyrain...@gmail.com> wrote:
>
> > 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 customers. It won't
> > be a
> >    popular choice across all Apache Polaris adoption. I have never
> >    heard anyone asking for it in the Polaris community.
> >    2. *Promoting realmId for multi-account usage* may make sense for
> NoSQL
> >    backends, which are typically distributed and scale well. I believe
> > this is
> >    what Snowflake and Dremio do with managed Polaris.
> >    However, this thread is focused on the *Postgres JDBC implementation*,
> >    which often runs on a single-node setup. In that case, Option 3 could
> >    introduce performance bottlenecks.
> >    3. *Option 1 provides stronger isolation*. A bug in the persistence
> >    layer or a misconfiguration at the RDBMS level could more easily cause
> >    cross-account data leakage without it. Remember that a realm may
> > represent
> >    environments like dev, QA, or prod,  isolation matters. (ref
> >    <
> >
> https://github.com/polaris-catalog/polaris/blob/main/polaris-core/src/main/java/org/apache/polaris/core/context/RealmContext.java#L23-L23
> > >).
> >    Plus, as Pierre said, a noisy neighbor could impact across-account
> >    performance, and keep in mind, it’s a single node database.
> >    4. A solution that mixes Option 1 and Option 3 would be a *breaking
> >    change*. It would require not only schema updates but also
> modifications
> >    to admin tooling like the bootstrap logic. If there's strong interest,
> > I’d
> >    suggest pursuing that as a *separate proposal*.
> >
> > Given all this, I don’t think the realmId schema change should block the
> > JDBC implementation work.
> >
> >
> > Yufei
> >
> >
> > On Tue, Apr 22, 2025 at 5:57 AM Alex Dutra <alex.du...@dremio.com.invalid
> >
> > wrote:
> >
> > > 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
> > > connection pools ourselves. I hope we are all aware of that and OK with
> > it.
> > >
> > > Thanks,
> > >
> > > Alex
> > >
> > > On Mon, Apr 21, 2025 at 11:06 PM Dmitri Bourlatchkov <di...@apache.org
> >
> > > wrote:
> > >
> > > > 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.
> > > >
> > > > My personal opinion is that we do not have to force users this way
> (and
> > > > offer deployment flexibility as discussed previously).
> > > >
> > > > I do not really see any operational ambiguity in option 3.
> > Administrators
> > > > have to define a DataSource anyway. Diligent Administrators have to
> > > > understand the JDBC schema anyway. If the config defaults are such
> that
> > > > reusing a DataSource for many realms is _not_ allowed, an
> Administrator
> > > > cannot mix data by mistake.
> > > >
> > > > Also, I believe the extra code complexity is negligible to the
> > complexity
> > > > of ensuring correct operation during concurrent updates.
> > > >
> > > > While it is not my intention to block going with option 1 only, I
> > believe
> > > > we have to make project decisions with clarity, therefore I raise
> this
> > > > point (again) and ask people to acknowledge that this is indeed the
> > > > direction we want to go.
> > > >
> > > > Thanks,
> > > > Dmitri.
> > > >
> > > > On Mon, Apr 21, 2025 at 1:22 PM Prashant Singh
> > > > <prashant.si...@snowflake.com.invalid> wrote:
> > > >
> > > > > 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 follows:
> > > > >
> > > > >    1. Following the precedent set by EclipseLink, the initial goal
> of
> > > the
> > > > >    JDBC implementation was to *replace* EclipseLink. This new
> feature
> > > > feels
> > > > >    like an addition to that core effort.
> > > > >    2. We anticipate revisiting schema changes when we discuss a
> > > separate
> > > > >    DAO for the Entity layer. This means the schema we're currently
> > > > > considering
> > > > >    isn't necessarily final.
> > > > >    3. Many users are eagerly awaiting the JDBC implementation due
> to
> > > the
> > > > >    scalability limitations of the current EclipseLink solution.
> > > > Decoupling
> > > > >    this might allow us to deliver the core JDBC benefits sooner.
> > > > >
> > > > > I'd love to hear your thoughts on this proposal.
> > > > >
> > > > > Best, Prashant
> > > > >
> > > > >
> > > > > On Fri, Apr 18, 2025 at 3:57 PM Yufei Gu <flyrain...@gmail.com>
> > wrote:
> > > > >
> > > > > > 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 strong, predictable isolation with minimal
> > > complexity
> > > > > and
> > > > > > fewer edge cases. Yes, if multiple realms are mixed in the same
> JVM
> > > > even
> > > > > > with option 1, isolation may still be compromised, but at least
> the
> > > > > design
> > > > > > makes this explicit and easier to reason about. Running one realm
> > per
> > > > > > Polaris instance is a reasonable solution for environments that
> > value
> > > > > > isolation, and option 1 just works, while option 3 adds
> unnecessary
> > > > > > complexity.
> > > > > >
> > > > > > I believe adding support for both option 1 and option 3
> introduces
> > > not
> > > > > just
> > > > > > code complexity, but also operational ambiguity and a burden on
> > users
> > > > to
> > > > > > fully understand the trade-offs. Instead of delegating this to
> > > admins,
> > > > we
> > > > > > should first aim for clarity and safety in the design.
> > > > > >
> > > > > > We can always revisit this in the future if a strong real-world
> use
> > > > case
> > > > > > arises. For now, I’d prefer we keep the design simple and
> > > unambiguous.
> > > > > >
> > > > > > Yufei
> > > > > >
> > > > > >
> > > > > > On Fri, Apr 18, 2025 at 3:17 PM Dmitri Bourlatchkov <
> > > di...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > 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
> > > > > > > changes and releases).
> > > > > > >
> > > > > > > Even with option 1 if multiple realms are mixed in memory, the
> > > > > isolation
> > > > > > > guarantees are not much stronger than with option 3. If the
> main
> > > > > concern
> > > > > > is
> > > > > > > strong isolation, then Polaris Servers should run with only one
> > > realm
> > > > > per
> > > > > > > instance (per JVM).
> > > > > > >
> > > > > > > I propose to delegate this decision to the Polaris admin.
> > > > > > >
> > > > > > > I do not think the code will have to be more complex to support
> > > both
> > > > > > > options 1 and 3 compared to option 1 alone. In fact, as far as
> I
> > > can
> > > > > > tell,
> > > > > > > supporting option 1 plus multiple realms per JVM is more
> complex
> > > than
> > > > > > > option 3 alone.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Dmitri.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Apr 18, 2025 at 4:38 PM Yufei Gu <flyrain...@gmail.com
> >
> > > > wrote:
> > > > > > >
> > > > > > > > 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 single realm, the concept of a realm becomes
> > > > > > > unnecessary.
> > > > > > > > In that case, there's no need for any additional options,
> > > including
> > > > > > > option
> > > > > > > > 3.
> > > > > > > >
> > > > > > > > Yufei
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Apr 15, 2025 at 11:19 AM Dmitri Bourlatchkov <
> > > > > di...@apache.org
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > > > collado.m...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > 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 because it
> > > means
> > > > > > > > > potentially
> > > > > > > > > > larger blast radius if database credentials are ever
> > leaked.
> > > > But
> > > > > if
> > > > > > > > most
> > > > > > > > > > end users are expecting to only manage a single realm,
> it's
> > > > > > probably
> > > > > > > > the
> > > > > > > > > > easiest and solves the most common use case.
> > > > > > > > > >
> > > > > > > > > > I like the option of combining 1 and 3 - by default, a
> > single
> > > > > > tenant
> > > > > > > > > > deployment writes to a single end database, but admins
> have
> > > the
> > > > > > > ability
> > > > > > > > > to
> > > > > > > > > > configure dynamic connections to different database
> > endpoints
> > > > if
> > > > > > > > multiple
> > > > > > > > > > realms are supported.
> > > > > > > > > >
> > > > > > > > > > Mike
> > > > > > > > > >
> > > > > > > > > > On Tue, Apr 15, 2025 at 9:32 AM Alex Dutra
> > > > > > > > <alex.du...@dremio.com.invalid
> > > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > 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 could be quite cumbersome
> > for
> > > > end
> > > > > > > users,
> > > > > > > > > > > making this option less user-friendly in practice.
> > > > > > > > > > >
> > > > > > > > > > > Regarding Option 2, while it's theoretically possible
> to
> > > > manage
> > > > > > > > > multiple
> > > > > > > > > > > schemas with a single datasource, implementing this can
> > be
> > > > > > complex.
> > > > > > > > To
> > > > > > > > > > > effectively work with different schemas in PostgreSQL,
> > you
> > > > > would
> > > > > > > need
> > > > > > > > > to
> > > > > > > > > > > either qualify all table identifiers or adjust the
> > > > > `search_path`
> > > > > > > URL
> > > > > > > > > > > parameter. Additionally, other JDBC backends like MySQL
> > > don't
> > > > > > > support
> > > > > > > > > > > multiple schemas per database, which would make Option
> 2
> > > less
> > > > > > > > portable
> > > > > > > > > > > across different JDBC databases.
> > > > > > > > > > >
> > > > > > > > > > > That's why I think Option 3 is the most portable one,
> and
> > > the
> > > > > > > easiest
> > > > > > > > > for
> > > > > > > > > > > users or administrators to configure. As Pierre noted,
> it
> > > is
> > > > > > > subject
> > > > > > > > to
> > > > > > > > > > > noisy neighbor interferences – but to some extent, I
> > think
> > > > > > > > > interferences
> > > > > > > > > > > could also happen with separate schemas like in option
> 2.
> > > > > > > > > > >
> > > > > > > > > > > Just my 2 cents.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > >
> > > > > > > > > > > Alex
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 15, 2025 at 4:00 PM Dmitri Bourlatchkov <
> > > > > > > > di...@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > 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
> > > > > > (including
> > > > > > > > > > > secrets).
> > > > > > > > > > > > If that is the deployment administrator, then the
> admin
> > > > > > > necessarily
> > > > > > > > > has
> > > > > > > > > > > to
> > > > > > > > > > > > be aware of all realms and effectively has control of
> > the
> > > > > data
> > > > > > in
> > > > > > > > all
> > > > > > > > > > > > realms. Isolation is achieved only for end users.
> > > > > > > > > > > >
> > > > > > > > > > > > That said, even with option 3 the deployment owner
> has
> > > > > control
> > > > > > > over
> > > > > > > > > all
> > > > > > > > > > > > realms and end users are isolated as far as their
> > access
> > > to
> > > > > > APIs
> > > > > > > is
> > > > > > > > > > > > concerned. End users cannot discover each other's
> data
> > > > > (barring
> > > > > > > > > coding
> > > > > > > > > > > > mistakes in Polaris). The same goes for option 2 as
> > it's
> > > > the
> > > > > > > middle
> > > > > > > > > > > ground.
> > > > > > > > > > > >
> > > > > > > > > > > > I do not see any material difference between options
> > 1, 2
> > > > > and 3
> > > > > > > > from
> > > > > > > > > > the
> > > > > > > > > > > > end user's perspective.
> > > > > > > > > > > >
> > > > > > > > > > > > If, however, the database connection parameters are
> not
> > > > > > > controlled
> > > > > > > > by
> > > > > > > > > > the
> > > > > > > > > > > > administrator, but by the end user who wants to
> define
> > a
> > > > > realm,
> > > > > > > > then
> > > > > > > > > > > > Polaris needs to expose managing database connections
> > and
> > > > > > > secrets.
> > > > > > > > > This
> > > > > > > > > > > may
> > > > > > > > > > > > be a valuable feature, but I believe it is far beyond
> > > > current
> > > > > > > > Polaris
> > > > > > > > > > > > backend capabilities. I do not think going this way
> is
> > > > > > justified
> > > > > > > at
> > > > > > > > > > this
> > > > > > > > > > > > time.
> > > > > > > > > > > >
> > > > > > > > > > > > I'd like to propose a hybrid approach where Polaris
> > > > provides
> > > > > > > > > > capabilities
> > > > > > > > > > > > (and config) for the administrators to choose between
> > > > options
> > > > > > 1,
> > > > > > > > 2, 3
> > > > > > > > > > > > according to their specific deployment concerns.
> > > > > > > > > > > >
> > > > > > > > > > > > This means that the primary key has to include the
> > realm
> > > > ID,
> > > > > > > > because
> > > > > > > > > if
> > > > > > > > > > > the
> > > > > > > > > > > > Polaris code does not provide it then the admin will
> > not
> > > be
> > > > > > able
> > > > > > > to
> > > > > > > > > > > choose
> > > > > > > > > > > > option 3 at runtime.
> > > > > > > > > > > >
> > > > > > > > > > > > WDYT?
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > Dmitri.
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Apr 15, 2025 at 8:35 AM Pierre Laporte <
> > > > > > > > > pie...@pingtimeout.fr>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > 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 of
> > the
> > > > > > > strongest
> > > > > > > > > > > > isolation
> > > > > > > > > > > > > mode.  However, the code would need to support a
> > > complete
> > > > > > > > database
> > > > > > > > > > > > > configuration per realm (think username and
> password
> > > and
> > > > > > > possibly
> > > > > > > > > IP
> > > > > > > > > > > > > address) if the goal is to match Postgres
> > capabilities.
> > > > In
> > > > > > > terms
> > > > > > > > > of
> > > > > > > > > > > > > backup/restore, it is the most flexible option.
> > > > > > > > > > > > >
> > > > > > > > > > > > > A "one schema per realm" approach would be a
> simpler
> > > > > > approach,
> > > > > > > > > > > regarding
> > > > > > > > > > > > > datasource configuration.  However, there would be
> > less
> > > > > > > isolation
> > > > > > > > > > > between
> > > > > > > > > > > > > realms, and a resource utilization spike on one
> realm
> > > > could
> > > > > > > > impact
> > > > > > > > > > > > > performance of another realm.  It is as flexible as
> > > > option
> > > > > #1
> > > > > > > > > > regarding
> > > > > > > > > > > > > backup and restore.
> > > > > > > > > > > > >
> > > > > > > > > > > > > A "realm as part of the primary key" approach is
> the
> > > most
> > > > > > > > efficient
> > > > > > > > > > > way,
> > > > > > > > > > > > in
> > > > > > > > > > > > > that the cost of adding tenants is close to zero.
> > Like
> > > > in
> > > > > > > option
> > > > > > > > > #2,
> > > > > > > > > > > > there
> > > > > > > > > > > > > is no real resource isolation between tenants and a
> > > > > > > > noisy-neighbor
> > > > > > > > > > > > > situation is a possible issue.  The biggest
> > difference
> > > is
> > > > > > > > regarding
> > > > > > > > > > > > backup
> > > > > > > > > > > > > and restore.  Consider the case where data is
> > > > accidentally
> > > > > > > > > > > > > wiped/corrupted/modified/... in a given tenant and
> > > > > > > administrators
> > > > > > > > > > want
> > > > > > > > > > > to
> > > > > > > > > > > > > restore it to a previous state.  With this
> approach,
> > it
> > > > is
> > > > > a
> > > > > > > much
> > > > > > > > > > more
> > > > > > > > > > > > > complex as Postgres does not (AFAIK) allow the
> > > > possibility
> > > > > to
> > > > > > > > > restore
> > > > > > > > > > > > > tables partially.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Just my 2 cents
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > >
> > > > > > > > > > > > > Pierre
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Apr 15, 2025 at 12:42 AM Prashant Singh
> > > > > > > > > > > > > <prashant.si...@snowflake.com.invalid> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Dear Polaris Community,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This email initiates a discussion regarding the
> > > > modeling
> > > > > of
> > > > > > > > > Realms
> > > > > > > > > > > > within
> > > > > > > > > > > > > > the Polaris project, following its recent mention
> > in
> > > my
> > > > > > JDBC
> > > > > > > > > > > > > implementation
> > > > > > > > > > > > > > pull request:
> > > > > > > > > > > > > >
> > > > > > > https://github.com/apache/polaris/pull/1287/files#r2040383971.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > My current understanding, based on available
> > > > information,
> > > > > > is
> > > > > > > > that
> > > > > > > > > > > > Realms
> > > > > > > > > > > > > > were primarily intended for isolation.
> > Consequently,
> > > > the
> > > > > > > > > > EclipseLink
> > > > > > > > > > > > > > implementation treats each Realm as a separate
> > > > database.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > As we are re-implementing this functionality, it
> > was
> > > > > > > suggested
> > > > > > > > > that
> > > > > > > > > > > we
> > > > > > > > > > > > > > gather community feedback on the optimal approach
> > to
> > > > > > modeling
> > > > > > > > > > Realms.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Based on my current understanding, here are
> > potential
> > > > > > > modeling
> > > > > > > > > > > options:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > *1. Separate Databases per Realm:*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    - Each Realm would correspond to a distinct
> > > > database.
> > > > > > > > > > > > > >    - This could be implemented using Quarkus
> custom
> > > > data
> > > > > > > > sources,
> > > > > > > > > > > with
> > > > > > > > > > > > > one
> > > > > > > > > > > > > >    data source per Realm.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > *2. Separate Schemas per Realm:*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    - Each Realm would correspond to a distinct
> > > database
> > > > > > > schema
> > > > > > > > > > > within a
> > > > > > > > > > > > > >    single database.
> > > > > > > > > > > > > >    - Most database systems support two-part
> > > > identifiers (
> > > > > > > > > > > > > >    <schema_name>.<table_name>), allowing for data
> > > > > > isolation.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > *3. Realm as a Primary Key:*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >    - A realm identifier would be added as a
> primary
> > > key
> > > > > (or
> > > > > > > > part
> > > > > > > > > > of a
> > > > > > > > > > > > > >    composite primary key) to each Polaris table.
> > > > > > > > > > > > > >    - Data isolation would be enforced through
> > > filtering
> > > > > > based
> > > > > > > > on
> > > > > > > > > > this
> > > > > > > > > > > > key
> > > > > > > > > > > > > >    during data access.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The optimal approach will likely depend on ease
> of
> > > use
> > > > > and
> > > > > > > > > > > > > maintainability
> > > > > > > > > > > > > > for database administrators.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Please share your thoughts and preferences
> > regarding
> > > > > these
> > > > > > > > > options.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Best regards,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Prashant Singh
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to