What's New

Amazon SageMaker Feature Store has introduced three new capabilities: BatchWriteRecord for high-throughput ingestion of multiple records across multiple feature groups in a single API call, ListRecords for paginated discovery of all records in a feature group without prior knowledge of record identifiers, and support for custom-named Glue and Iceberg tables in the offline store. These additions eliminate the need for custom tooling to manage feature ingestion at scale and to audit or govern feature group contents. The update is generally available across all AWS Regions where SageMaker Feature Store is supported.

How It Works

• BatchWriteRecord: Accepts multiple records targeting multiple feature groups in a single API request, directing writes to the online store, offline store, or both simultaneously, reducing round-trip latency compared to sequential PutRecord calls.
• Partial failure handling: BatchWriteRecord returns per-record failure details without aborting the entire batch, allowing callers to identify and retry only the failed records.
• Time-to-live (TTL) support: TTL settings can be applied at three granularities — individual record, batch request, or feature group level — giving fine-grained control over record expiration in the online store.
• ListRecords: Returns paginated lists of record identifiers stored in a feature group, enabling browsing and auditing without requiring the caller to already know the record IDs.
• Custom offline store naming: When configuring an OfflineStore, the DataCatalogConfig object in OfflineStoreConfig now accepts custom database and table names for both Glue and Apache Iceberg table formats, overriding the auto-generated naming convention.
• Glue table creation control: The DisableGlueTableCreation flag can be set to True to associate a custom catalog configuration without having Feature Store create the table, leaving table management to the operator (note: Iceberg format requires this flag to be False).
• API surface: All new runtime operations (BatchWriteRecord, ListRecords) are exposed through the Amazon SageMaker Feature Store Runtime API endpoint alongside existing operations such as PutRecord, GetRecord, BatchGetRecord, and DeleteRecord.

Why It's Important

• Throughput at scale: Writing features one record at a time via PutRecord becomes a bottleneck for large-scale pipelines; BatchWriteRecord dramatically reduces API call overhead and end-to-end ingestion latency for high-volume workloads.
• Operational resilience: Partial-failure semantics mean a single bad record no longer blocks an entire ingestion batch, improving pipeline reliability and simplifying error-handling logic.
• Audit and governance: ListRecords enables data scientists and ML engineers to enumerate feature group contents for compliance audits, data quality checks, and lifecycle management without maintaining a separate index of record IDs.
• Catalog flexibility: Custom Glue/Iceberg table names allow organizations to enforce naming conventions, integrate with existing data governance frameworks, and avoid conflicts in shared Glue Data Catalogs.
• Reduced custom tooling: Teams previously had to build wrapper services or orchestration logic to batch writes or discover records; these capabilities are now native, reducing maintenance burden and time-to-production.
• TTL lifecycle management: Record-level TTL support enables automatic expiration of stale features in the online store, keeping serving latency low and storage costs controlled without manual deletion jobs.

How It's Different

• vs. PutRecord (single-record write): BatchWriteRecord consolidates what previously required N sequential API calls into one request, lowering per-record API overhead and network round-trips significantly.
• vs. manual record tracking: Before ListRecords, teams had to maintain external registries or query the offline store (e.g., via Athena) to discover which records existed in a feature group; ListRecords provides this natively through the runtime API.
• vs. auto-generated offline table names: Previously, Feature Store auto-generated Glue table and database names following Athena conventions; custom naming is now a first-class configuration option, enabling alignment with enterprise naming standards.
• vs. all-or-nothing batch semantics: Many batch APIs fail the entire request on any error; BatchWriteRecord's per-record failure reporting is a more resilient design that avoids unnecessary retries of successfully written records.
• TTL granularity advantage: Competing feature stores and the prior Feature Store API lacked multi-level TTL control; the record/request/feature-group hierarchy provides more precise expiration management than a single group-level setting.

When to Prefer It

• High-frequency feature pipelines: Use BatchWriteRecord when ingesting features from streaming sources (e.g., Kinesis, Kafka) or scheduled batch jobs where thousands of records must be written per second and API call count is a cost or latency concern.
• Multi-feature-group fan-out: When a single event or data record must update features across several feature groups simultaneously, BatchWriteRecord's cross-group support eliminates the need for parallel PutRecord calls.
• Feature auditing and compliance workflows: Use ListRecords when you need to enumerate all records in a feature group for data lineage reports, GDPR/CCPA deletion verification, or periodic data quality scans.
• Record lifecycle management: Use ListRecords combined with DeleteRecord to implement custom retention policies, identifying and purging records that meet expiration criteria.
• Enterprise data catalog integration: Use custom offline store table naming when your organization has a governed Glue Data Catalog with enforced naming conventions, or when multiple teams share a catalog and need to avoid table name collisions.
• Short-lived or session-based features: Use record-level TTL in BatchWriteRecord when ingesting ephemeral features (e.g., session activity, real-time fraud signals) that should automatically expire from the online store after a defined window.
• Recovering from ingestion failures: Use BatchWriteRecord's partial-failure response to build idempotent retry logic that reprocesses only failed records, rather than replaying entire batches.

Availability

• GA status: Generally available as of July 9, 2026; no preview or beta restrictions noted.
• Regional availability: Available in all AWS Regions where Amazon SageMaker Feature Store is currently supported; refer to the AWS Regional Services List for the full region matrix.
• Pricing: No separate pricing announced for the new API operations; standard SageMaker Feature Store pricing for online store writes, offline store storage, and data processing applies — consult the SageMaker Feature Store pricing page for current rates.
• Iceberg limitation: Custom offline table naming with DisableGlueTableCreation=True is not supported for the Apache Iceberg table format; Iceberg requires DisableGlueTableCreation to be False.
• API access: New operations (BatchWriteRecord, ListRecords) are available via the SageMaker Feature Store Runtime API endpoint and supported in AWS SDKs (C++, Java V2, Ruby V3, and others).
• Pagination: ListRecords returns results one page at a time; callers must implement pagination logic using the returned next-page token for feature groups with large record counts.

Related Resources

• https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/
• https://aws.amazon.com/sagemaker/ai/feature-store/
• https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_Operations_Amazon_SageMaker_Feature_Store_Runtime.html
• https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_OfflineStoreConfig.html#sagemaker-Type-OfflineStoreConfig-DisableGlueTableCreation