# Pulse · August 8, 2026

> AWS extends legacy OpenSearch support a year, OpenAI sets an August 17 deadline for automatic ad-conversion matching, and BigQuery's AI.SEARCH reaches GA.

Canonical: https://brandonlazovic.dev/pulse/2026-08-08/  
Author: Brandon Lazovic  
Published: 2026-08-08

## AWS pushes legacy Elasticsearch and OpenSearch support end dates back 12 months, to November 2027

Status: Confirmed  |  Topics: platform-ecommerce, ai-data-stack

AWS pushed back Extended Support end dates for legacy Elasticsearch (1.5-7.8, excluding 5.6) and OpenSearch (1.0-1.2, 2.3-2.9) on Amazon OpenSearch Service by 12 months, from November 7, 2026 to November 7, 2027, an August 7 AWS Big Data Blog post says. That extended pricing still roughly doubles instance-hour cost. Elasticsearch 5.6 keeps its original 2028 end date. AWS also set new, later end-of-support dates for Elasticsearch 6.8/7.9/7.10 and OpenSearch 1.3, 2.11-2.19, running 2027-2030 at a flat $0.0065-per-hour surcharge instead.

In plain terms: Amazon OpenSearch Service is AWS's managed version of the open-source search engine many e-commerce sites use for on-site product search; 'Extended Support' is a paid grace period for old versions before AWS stops patching them.

Why it matters: Teams running on-site product search, log analytics, or other search infrastructure on legacy OpenSearch or Elasticsearch versions get another year before a forced upgrade or a support-tier price jump.

Our take: A 12-month reprieve on a support deadline is a budget-planning signal more than a technical one: teams that had penciled in a forced migration this year can now sequence it against other roadmap work instead of a hard cutoff. The pricing detail worth flagging upward is that the doubled surcharge only hits versions already past standard support today; newer versions AWS just added to the program pay a smaller flat add-on instead, so the two groups need separate line items in a renewal forecast.

- [AWS Big Data Blog: Amazon OpenSearch Service extends version lifecycle support timelines](https://aws.amazon.com/blogs/big-data/amazon-opensearch-service-extends-version-lifecycle-support-timelines/)

## OpenAI sets August 17 to auto-enable Automatic Advanced Matching on existing ChatGPT Ads pixels

Status: Confirmed  |  Topics: chatgpt-assistants, ads-paid

OpenAI's Help Center confirms Automatic Advanced Matching (AAM) is now default for new ChatGPT Ads web pixels, and on August 17, 2026 OpenAI will auto-enable it for existing pixels. AAM hashes visitor form data with SHA-256 in-browser to match conversions when no click identifier exists. Advertisers can opt out under Tools, Conversions, Data Source. OpenAI also published a dedicated Ads Manager Beta setup guide for conversion-optimized (oCPC) campaigns, first disclosed in a July 27 advertiser email.

In plain terms: Automatic Advanced Matching quietly scrambles (hashes) a visitor's name, email, or phone number from your site's forms so OpenAI can still credit a purchase to an ad even when it cannot track the click directly.

Why it matters: Advertisers running ChatGPT Ads pixels have until August 17 to review or opt out of automatic customer-data matching, and oCPC now has documented setup steps rather than just an email announcement.

Our take: In 'OpenAI's feed pivot,' I argued the organic product feed and the ads feed are architecturally separate, gated by different fields with no crossover between them. AAM and a dedicated oCPC setup guide fit that same pattern: OpenAI keeps shipping campaign-side tooling on the ads pipeline specifically, while the organic feed gets no equivalent attention.

- [OpenAI Help Center: Conversion Measurement](https://help.openai.com/en/articles/20001409-conversion-measurement)
- [OpenAI Help Center: Conversion-optimized Campaigns](https://help.openai.com/en/articles/20001412-conversion-optimized-campaigns)

## BigQuery's AI.SEARCH function reaches general availability, Google claims up to 133x slot-efficiency gains

Status: Confirmed  |  Topics: ai-data-stack

Google Cloud made AI.SEARCH() and autonomous embedding generation in BigQuery generally available on August 7, 2026, per its Data Analytics blog. AI.SEARCH() delivers up to 133x better slot efficiency for single-query natural-language search without a separate embeddings pipeline. Autonomous embeddings now also support images via ObjectRefs for multimodal search, and a new Hybrid Search mode, combining vector and BM25 keyword search with Reciprocal Rank Fusion reranking, enters public preview.

In plain terms: AI.SEARCH lets you type a plain-English question against a BigQuery table and get ranked results back, without first converting every row into the number-based 'embeddings' a vector database normally needs; general availability means it is now production-supported, not a preview.

Why it matters: Teams building AI-powered product or content search directly in BigQuery no longer need a separate vector database, and GA status plus a concrete efficiency number make it a credible default rather than an experimental option.

Our take: The 133x figure is a vendor benchmark on a single-query workload, not an independent apples-to-apples comparison, so teams should validate slot-efficiency gains against their own query mix before consolidating a search stack onto BigQuery. Hybrid Search's public-preview status also means the BM25-plus-vector reranking is not yet production-SLA-backed.

- [Google Cloud Blog: BigQuery search innovations unify structured, unstructured data](https://cloud.google.com/blog/products/data-analytics/bigquery-search-innovations-unify-structured-unstructured-data/)