01 / PURPOSE

Ident’s control plane.
Your infrastructure choice.

IASD (Ident Advanced System Database) is the planned expanded identity and product direction for IdentDB, an existing, independently developed database system. Its developing management experience is intended to bring relational and JSON document workflows into a coherent Ident workspace.

The proposal would let customers choose Supabase Cloud as an infrastructure provider alongside Ident-hosted options. Supabase Cloud would be optional. Existing Ident authentication, project permissions and application integrations would remain part of the control plane.

The customer problem

Developers often move between database consoles, application permissions and provider dashboards. IASD aims to reduce that management friction: clearer project context, unified administration and a choice of infrastructure, with portability where schemas, data models and provider interfaces technically permit it. It does not promise identical features or automatic conversion between relational and document databases.

02 / FACTUAL BASELINE

What exists. What is proposed.

03 / TECHNICAL DIRECTION

Planned architecture

Ident would resolve its own user and project permissions before a provider request. Supabase authorisation would establish the separate provider-side permission boundary. An Ident login alone would not authorise access to a customer’s Supabase account, and a management authorisation would not be treated as unrestricted database-row access.

Provider reference: Supabase’s OAuth integration guide and Management API reference. These describe Supabase’s interfaces, not an implemented Ident connection.

04 / ILLUSTRATIVE ONLY

A proposed developer workflow

These are design steps for an unreleased integration. They are not setup instructions, working endpoints or a promise that every provider operation will be available.

1. Review and authorise.

   A customer with appropriate Ident and Supabase authority would review the purpose and requested provider permissions before consenting through a supported Supabase flow.

2. Choose a project.

   IASD would list only projects available under that authorisation, bind the selected provider project to the intended Ident project, and show its ownership and region context.

3. Use permitted capabilities.

   The interface would identify which metadata, SQL or service operations are supported and permitted. Missing access or unsupported operations would be visible rather than silently bypassed.

4. Understand the data path.

   Metadata and customer-requested database content would pass through the required Ident and provider services. Data access, any caching and retention would need documented purposes and controls before release.

5. Disconnect and revoke.

   The design must stop future Ident access and remove reusable provider credentials when disconnected, with provider-side revocation guidance. Disconnecting would not automatically delete the customer’s Supabase project or its data.

05 / PROVIDER BOUNDARIES

Feature scope and dependencies

Provider terms, quotas, pricing, supported regions and network constraints remain applicable. Supabase Cloud is not included free with an Ident account. No speed, scale or zero-downtime failover claim is made. AWS, Google Cloud or dedicated-server combinations are longer-term possibilities, not completed hybrid infrastructure.

06 / RELEASE REQUIREMENTS

Security, privacy and ownership

The Cloud connection is not implemented, so the following are requirements for its design and acceptance testing, not claims of deployed protection.

Least privilege

Request only permissions justified by the chosen capability; test denied and revoked access. Supabase and Ident permissions must both be respected. See Supabase OAuth scopes.

Credential handling

Keep reusable provider tokens and privileged database credentials out of public pages, browser bundles, URLs and routine logs. Define protected storage, rotation, expiry and revocation before collecting them.

Tenant isolation

Bind every provider operation to the authorised Ident user, organisation/project and selected Supabase project. Verify cross-tenant denial rather than relying on a project ID supplied by the browser.

Auditability

Record relevant authorisation and administrative actions without copying credentials or unnecessary query content into logs. Define retention and access controls before release.

Regions and data access

Explain where provider data lives and where Ident processes requests; selecting a database region alone does not establish an end-to-end residency guarantee. Confirm service availability against Supabase’s region documentation.

Responsibilities

Customers retain responsibility for authorising access, their database policies and appropriate data use. Ident and provider responsibilities, subprocessors and retention must be described for the actual connection model before launch. Existing notices are available at Ident privacy and the Trust Centre.

07 / AVAILABILITY

Milestones, without an invented date.

The integration is scoped and planned. There is no generally available Cloud connection, published launch date or open migration programme.

Scope can change after technical, provider and commercial review. Any future release would need separate testing and verified publication.

09 / FOR SUPABASE REVIEWERS

A proposed adoption path,
not an agreed partnership.

IDENT GROUP LTD is seeking a Supabase integration partnership for IASD’s optional infrastructure-provider direction. The technical proposal is an Ident-managed user experience over supported Supabase authorisation and management interfaces, initially for customer-owned projects.

If implemented and adopted, this could introduce developers using Ident’s administration and document workflows to Supabase-managed PostgreSQL and, where appropriate, storage or realtime services. Infrastructure consumption would depend on actual customer choices and usage. There are no verified adoption forecasts, committed volumes, agreed revenue terms or funding/credit awards to report.

This page documents the scope being proposed. It does not assert that Supabase has accepted an application, approved a partnership or endorsed IdentDB or IASD.