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 with the need for strong realm isolation in memory too, I think current functionality is adequate for sensitive environments. I'm ok with keeping the current state of DataSource configuration in the JDBC Persistence until we get specific requests from users for separating realms in the database, but sharing JVM memory across realms. Cheers, Dmitri. On Tue, May 13, 2025 at 1:29 PM 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
