Search servers

A search server is the engine that actually indexes and ranks your records. Searchability is a thin, multi-tenant gateway in front of it: the gateway owns the schema, the versioning, the public API and the prebuilt components, while the search server does the physical indexing, tokenisation and query execution. When you create a list, you choose which server hosts it — and because the gateway sits in front, that choice is invisible to your app.

In the console these are managed under Search Services. While you’re prototyping you can ride on our shared servers with zero setup; for production you register a server you own, for dedicated capacity and full data ownership.

Auto-plays · use Back / Next to step through at your own pace.

Who does what

Register a server

1. Go to Search Services → Add Search Service and pick a provider — Azure AI Search, Amazon OpenSearch, Elasticsearch or PostgreSQL.
2. Give it a name, its endpoint and key, and pick the nearest region — the region is used to route queries down the lowest-latency path.
3. Add it. The server now hosts lists: one server can hold many lists, and one account can register many servers, each with its own capacity.

Shared vs. owned

• Shared (prototyping) — zero setup, but rate-limited and shared with other evaluation users. Perfect for building and trying things out.
• Owned (production) — you register your own cluster: dedicated capacity, your own scaling and private networking, and full data ownership. This is the path to going live.

Capacity and slots

Each search server has a finite number of index slots — the number of list indexes it can hold. Every list version you keep occupies a slot on its server, so a server with many lists (or many retained versions) fills up. As a server nears its limit the console warns you, and you either free slots (retire old versions) or register another server and spread lists across both. Owning your own server means that ceiling is yours to raise — scale the underlying cluster up and its slot budget grows with it.

Moving a list between servers — your URLs never change

Because your app talks to the Searchability gateway, not the server directly, a list can be transferred from one server to another with no client changes at all. The transfer copies the records to the new server and re-points the public API behind the scenes; your list’s search and suggest URLs stay exactly the same. That’s what lets you start on a shared server and graduate to your own, or move a list closer to your users, without a migration project or a code change.

Regions

You pick each server’s nearest region when you register it, and the gateway uses it to route requests along the lowest-latency path. Put a server near the users it serves; register servers in more than one region and host each list where its audience is, all under one account.

A worked example

You prototype a products list on the shared server — nothing to set up, and the public API works immediately. When you’re ready for production you register your own Azure AI Search service in the region nearest your customers, then transfer the list onto it. The records copy across, the API re-points itself, and the search URL your storefront already calls is unchanged — the only difference your users notice is that results now come from dedicated capacity you control. Later, as you keep more versions and the server approaches its slot limit, the console warns you in good time, and you register a second server to grow into.