altengine

Published · altengine team

The App Engine Search API Is Gone: Your Real Options in 2026

App Engine's Search API is retired, and there is no like-for-like drop-in. In 2026 you have three real replacement paths: run your own search cluster, adopt a large hosted search service, or move to a service that preserves App Engine's Search semantics over a REST API. This post lays out the honest trade-offs of each — including altengine's, where the query language, field types, facets, and sorting carry over while you rewrite the call layer.

First, know what you're actually replacing

The App Engine Search API was never just "full-text search." What made it worth keeping was a specific shape:

  • A structured document model — documents with typed fields: tokenized text, exact-match atom, number, date, and geo points.
  • A boolean query language — field-scoped terms, phrases, numeric and date comparisons, OR/NOT grouping, stemming.
  • Facets, sorting, and pagination — faceted navigation and rank- or field-based ordering built in.
  • No cluster to run — it was a managed index, billed roughly by usage and storage, not by a fleet you kept warm.

When you evaluate a replacement, weigh it against all four — not just "does it do full-text search." A tool can be excellent at search and still cost you a full rewrite of every query you've written. That rewrite cost is the thing most comparisons skip, so it's the thing we'll keep in view below.

Option 1: Run your own search cluster

The self-hosted route means standing up an open-source search engine — the OpenSearch/Elasticsearch family, or a lighter engine like Meilisearch or Typesense — on infrastructure you own.

What you gain: total control. You pick the version, the analyzers, the ranking, the hardware. There is no per-operation bill and no vendor to age out your API. For a team that already runs stateful services and has real search requirements, this is often the right long-term home.

What it costs: operations. You are now on the hook for capacity planning, sharding, replication, upgrades, backups, and the pager when a node falls over. And a search cluster is an always-on cost — the nodes bill whether or not anyone is querying. For a small or spiky app, you pay for an idle cluster most of the month. The migration itself is also a full rewrite: none of App Engine's query syntax, field types, or facet model maps onto these engines directly, so every query and index definition is redesigned from scratch.

Choose this if: you have ops capacity, meaningful scale, and search-specific needs (custom analyzers, vector search, exotic ranking) that justify owning the stack.

Option 2: A large hosted search service

Services like Algolia and Elastic Cloud hand you a managed, high-quality search product with strong developer tooling, dashboards, and features App Engine never had — typo tolerance, instant-search UIs, analytics, vector and hybrid search.

What you gain: excellent developer experience and a feature ceiling far above the legacy API. Someone else runs the cluster. If search is central to your product and you want best-in-class relevance tooling, this tier delivers.

What it costs: two things worth going in eyes-open about. First, pricing that grows with scale — these services meter on records, operations, or a mix, and the bill can climb steeply as your document count and query volume grow. That's fair for what they provide, but it's a different economic shape from "a managed index that costs a bit of storage." Check the specific metering model against your own volumes before committing; don't assume the entry tier reflects your steady-state bill. Second, the migration is again a full model rewrite: their document schemas, query DSLs, and faceting are their own, so your App Engine queries don't carry over. You're re-learning and re-implementing your search layer, not porting it.

Choose this if: search is a core product surface, you want advanced relevance and UI tooling, and the pricing works at your scale.

Option 3: altengine — App Engine Search semantics over REST

altengine's Search API is a revival aimed squarely at the case the first two options overshoot: you had working App Engine search, you want it back, and you don't want to redesign your query layer or run a cluster to get it.

The contract here is parity of semantics. The query language, field types, facets, and sorting behave the way you remember — but you reach them over altengine's own REST/JSON API rather than App Engine's language SDK. This is not drop-in and we won't pretend otherwise: you rewrite the call layer from the SDK to HTTP requests. What you don't rewrite is the search design itself — your queries and document schemas carry over.

Concretely, a search is a POST to an index, and the query string is the syntax you already know:

POST /v1/search/catalog/ns/_default/idx/films/search
Authorization: Bearer ae_yourkeyid.your-api-key-secret

{
  "query": "genre:comedy rating > 3",
  "sort": [{ "expr": "rating", "desc": true }],
  "facet_discover": 5,
  "limit": 20
}

Documents keep the typed-field model — text, atom, number, date, geo — and you put them in batches:

POST /v1/search/catalog/ns/_default/idx/films/documents

{ "documents": [
  { "id": "f1", "fields": [
    { "name": "title",  "type": "text",   "value": "Up in the Air" },
    { "name": "genre",  "type": "atom",   "value": "drama" },
    { "name": "rating", "type": "number", "value": 4 }
  ] }
] }

The query forms you leaned on all transfer: field scoping (title:air), numeric and date comparisons (released < 2011-02-28), boolean grouping (genre:(comedy OR drama)), phrases, and stemming. Facets work the App Engine way — attach facets to documents, ask for facet_discover, and pass the values a user picks back as facet_refinements to narrow the set. The full grammar and request shape are in the Search API reference.

The cost shape: no idle cluster

This is the biggest departure from the self-hosted and cluster-backed options. There's nothing running to pay for when you aren't searching. Search bills on queries plus the same three axes as storage — reads, writes, and stored data:

  • Queries — a flat $0.50 per 10,000 search requests.
  • Reads — $1.00 per million, metered by rows examined (one read = up to 100 rows). A selective query is a read or two; a repeated identical query is served from cache and bills zero reads — just its query.
  • Writes — $2.50 per million rows written (a document put writes its row plus its index rows).
  • Stored data — $0.80 per GB-month, covering documents plus their index.

There's one pay-as-you-go plan, the first $3.00 of usage each month is free for every organization, and there's no credit card required to start. An index you aren't querying costs only its storage. For a small or spiky app, that's the number that actually matters — you're not renting a cluster to sit idle. Full rates and worked examples are on the pricing page.

Choose this if: you're migrating off App Engine (or want that same simple shape on a new app), you value predictable usage-based cost over a large feature ceiling, and you'd rather port your queries than redesign them.

An honest comparison

None of these is strictly best — they're different trade-offs:

  • Migration effort: self-hosting and big hosted search both mean a full search redesign. altengine means rewriting the call layer while queries and schemas carry over — less conceptual work, but still real work.
  • Ops burden: self-hosting is highest; the two managed options are near zero.
  • Cost shape: a self-hosted or cluster-backed service is an always-on bill; altengine has no idle cluster and meters on usage. Large hosted services can be excellent value at some scales and expensive at others — check your volumes.
  • Feature ceiling: big hosted search wins on advanced relevance, vector/hybrid search, and UI tooling. altengine targets App Engine parity, not a superset — if you need vector search today, that's a point in the hosted services' favor.

If your honest requirement is "give me the App Engine Search API back, without a cluster and without a rewrite of every query," altengine is built for exactly that. If you need a search platform your app didn't previously have, one of the other two may fit better.

Getting started

Create an organization in the console, mint an API key with a write grant, and POST your first document — the index is created on first write. From there, point your existing App Engine queries at the REST endpoint and they should behave the way you remember. The API docs cover auth, grants, and errors; the Search reference covers the full query language and request shape.

Start free in the console

← Back to the blog