AI FDE create_object_type defaults to Object Storage V1 — no way to select V2 at creation time

Product Feedback
,
1

TL;DR

When creating an Object Type through the AI FDE create_object_type tool, the Object Type is always registered against Object Storage V1 (Phonograph). The tool does not expose a parameter to select Object Storage V2, and OSv2 does not appear to be the default. This forces a manual post-creation migration from Ontology Manager, which is expensive for large Object Types. Requesting that OSv2 be made the default — or, at minimum, that an objectStorageVersion parameter be exposed.

Environment

  • Feature: AI FDE → create_object_type

  • Object Type: ~702M rows, 59 properties, 2 many-to-one link types

  • Source dataset: Pre-processed transactional dataset in Foundry

  • Link targets: Store (via store ID), Product (via SKU)

What happened

Using AI FDE end-to-end, I:

  1. Added composite PK and foreign-key columns (SELL_IN_ID, store FK, SKU FK) to the source dataset via a transform.

  2. Validated match rates against the Store and Product master Object Types (Store: 100% master coverage; Product: 93.3% row coverage).

  3. Created the Object Type with 59 properties (currency formatting, visibility, Spanish descriptions).

  4. Created both link types (many-to-one to Store and to Product).

  5. Merged the proposal to production.

Everything merged cleanly and the Object Type indexed. However, immediately after merge, Ontology Manager surfaced the following warning:

Migrate <object_type> to Object Storage v2 for increased performance during linked object operations. See documentation for more information.

The Object Type had been silently registered in Object Storage V1 (Phonograph) — the legacy backend.

Expected behavior

Either of the following would resolve this:

  1. Preferred: create_object_type defaults to Object Storage V2, in line with Palantir’s recommended standard and V1’s deprecation path.

  2. Minimum: The tool exposes an objectStorageVersion (or equivalent) parameter so the caller can select V1 or V2 at creation time.

Impact

For a 702M-row Object Type with many-to-one links to two high-cardinality Object Types, the performance delta between V1 and V2 is material:

Capability Object Storage V1 (Phonograph) Object Storage V2
Linked-object operations at scale Slow Optimized
Max edit size 32 KB 3 MB
Edit-only properties Not supported Supported
Indexing throughput Slower Faster
Search-around at 700M+ rows Can be slow Optimized

The practical consequences of the V1 default:

  • Unnecessary re-indexing cost. A migration for a ~700M-row Object Type requires a full reindex that can run for hours.

  • Operational risk window. Until migration completes, search-around and linked-object queries against the new Object Type run on the slower backend in production.

  • Deprecation debt. Net-new Object Types are being created on a backend that is on a deprecation path.

Workaround

Migrate manually from Ontology Manager after creation:

  1. Open the Object Type in Ontology Manager.

  2. Navigate to Datasources → Indexing Metadata.

  3. Select Object Storage V2 and run through the migration wizard.

  4. Wait for full reindex (can take hours at 700M+ rows).

:warning: Caveat: In my case the migration option is not yet visible in Ontology Manager, likely because the Object Type is still completing its initial V1 indexing. The workaround has to be retried once the initial index finishes — adding another delay on top of the migration reindex itself.

Request

Please consider one of the following changes to create_object_type:

  1. Change the default to Object Storage V2 for all newly created Object Types.

  2. Expose a parameter (e.g. object_storage_version) that allows the caller to choose V2 at creation time.

Happy to share additional detail from this specific engagement if it’s helpful for reproducing or scoping the change.