Database Profiles

Map the 12 abstract model types to concrete vendor-specific database types using database profiles, with support for 13 built-in vendor templates and structural properties for NoSQL databases.

February 15, 2026

A database profile maps each of the 12 abstract model types to a concrete type for a specific database vendor. The central data model uses abstract types (string, integer, boolean, etc.) so that a single model supports multiple target databases simultaneously. Profiles bridge the gap between the vendor-agnostic model and the physical database by defining the exact type, parameterised template, and naming convention for each vendor.

What a Profile Contains

Each database profile is stored as a .neoarc-db-profile.json file under .neoarc-project/profiles/. It defines the vendor, a set of 12 type mappings (one per abstract type), and an optional naming convention that controls how entity and property names are formatted for that vendor.

Supported Vendors

NeoArc Studio includes built-in templates for 13 database vendors, selected via a typeahead that also accepts custom vendor names. Each template pre-populates the 12 type mappings, assigns the vendor's conventional naming format, and provides structural properties where applicable (e.g. PartitionKey/RowKey for Azure Table Storage).

Parameterised Templates

Type mappings optionally include a parameter template that substitutes property constraints into the concrete type string. When a property has constraint values set (such as maxLength or precision), the template replaces placeholders with those values at resolution time.

{
  "abstractType": "string",
  "concreteType": "NVARCHAR",
  "parameterTemplate": "NVARCHAR({maxLength})",
  "notes": "Defaults to NVARCHAR(MAX) when maxLength not specified"
}

Fidelity Loss Detection

When switching a view from one profile to another, certain abstract types may lose fidelity in the target database. NeoArc Studio detects these cases and displays warnings.

Creating a Database Profile

Follow these steps to add a new database profile to your project.

Profile File Structure

A complete profile file contains the schema version, vendor information, 12 type mappings, and the naming convention.

{
  "schemaVersion": "1.0.0",
  "id": "b2e4f8a1-3d7c-4e9b-8f6a-1c5d2e7b9a03",
  "name": "PostgreSQL 16",
  "vendor": "postgresql",
  "description": "Standard PostgreSQL type mappings with snake_case naming",
  "typeMappings": [
    { "abstractType": "string", "concreteType": "VARCHAR", "parameterTemplate": "VARCHAR({maxLength})" },
    { "abstractType": "integer", "concreteType": "INTEGER" },
    { "abstractType": "float", "concreteType": "DOUBLE PRECISION" },
    { "abstractType": "decimal", "concreteType": "NUMERIC", "parameterTemplate": "NUMERIC({precision},{scale})" },
    { "abstractType": "boolean", "concreteType": "BOOLEAN" },
    { "abstractType": "date", "concreteType": "DATE" },
    { "abstractType": "datetime", "concreteType": "TIMESTAMP WITH TIME ZONE" },
    { "abstractType": "uuid", "concreteType": "UUID" },
    { "abstractType": "json", "concreteType": "JSONB" },
    { "abstractType": "text", "concreteType": "TEXT" },
    { "abstractType": "binary", "concreteType": "BYTEA" },
    { "abstractType": "enum", "concreteType": "TEXT", "notes": "Use CREATE TYPE ... AS ENUM for native enums" }
  ],
  "namingConvention": "snake_case"
}

How Views Use Profiles

Each ERD view and graph view references a single database profile via its databaseProfileId field. When the view loads, it calls resolveType() on every property to convert abstract types to concrete types, and resolveName() on every entity and property name to apply the naming convention. Switching profiles from the top bar dropdown triggers a full re-resolution of all types and names in the view.

Structural Properties

Some databases require structural properties beyond regular type mappings. These are database-specific keys and metadata columns that are fundamental to how the database operates. For example, Azure Table Storage requires a PartitionKey and RowKey for every entity, Amazon DynamoDB uses pk and sk for single-table design, and Apache Cassandra needs partition keys and clustering columns.

Structural properties are defined on the database profile and appear in the profile creation dialog when using a vendor template that includes them. They can also be added manually to any profile.

Scope Types

Global: The structural property applies to every entity using this profile. Azure Table Storage's PartitionKey is always required regardless of which entity you are working with.

Per-entity: The structural property needs explicit configuration per entity. Cosmos DB's partition key path varies by container, so each entity specifies which property feeds into the partition key.

Impact Analysis

When a model property that contributes to a structural key is renamed, deleted, or has its type changed, the impact analysis system flags the change as high severity. This is because structural key derivation directly affects how data is partitioned and stored. The intent graph tracks these relationships via derives-structural-prop edges, so all downstream effects are visible before confirming a change.