Account Resources

Solr Traffic Bandwidth

Opensolr does not bill by the number of requests. It bills the bytes your index sends back. A tight query and a sloppy one cost the same to make, but not the same to answer.

One gigabyte of bandwidth is a million lean responses, or one heavy one. What you ask for decides which.

01 · What is counted

On a pre-paid plan you are billed for the outgoing bytes sent from your Opensolr index to your site or app. Nothing else. Not the number of queries, not the size of your index, not the traffic your own site receives.

Every field you return, every row you fetch and every facet you do not need is bandwidth. Return only the fields the page shows, page results instead of pulling thousands of rows, and use filters so the index does the narrowing. The best practices guide covers each of these.

02 · Why is my bandwidth high

Whoever reaches your search page, human or bot, triggers a query. The response coming back from the index is the part that counts.

Bots and crawlers visit search pages far more than people do, and each visit becomes a query against your index.
Heavy responses multiply that. A search page that returns full documents with every field makes every bot visit expensive.
A sudden overnight spike is almost always a crawler loop or a scripted attack on the search page, not real visitors.

03 · How to send fewer bytes

Return only what you show

Use rows and fl so each answer carries the results and the fields the page displays, and nothing else. Returning 100,000 records to display 10 is the most common cause of a bandwidth spike.

/select?q=mysearch&rows=10&fl=id,title

Cache on your side

Keep search results in your own cache (Redis, Memcached, whatever your framework offers), so a page reload, an autocomplete keystroke or a back-button click does not query the index again.

Let the index narrow

Filter with fq and page through results, instead of fetching thousands of rows and filtering them in your code.

Split the traffic across two indexes

Bandwidth is counted per index. Replicate index A into index B and let your application query both in turn: two indexes, two monthly allowances.

04 · Where to see who is using it

Request log API

Query and facet the request log of your index by any field. Facet by IP and path to see exactly who uses the bandwidth: API: Get Index Request Log.

Query Analytics

Traffic over time, popular queries and slow queries, per index, in the control panel: Query Analytics.

Live Query Stream

Every request as it arrives, so a crawler loop or an attack shows the moment it starts: Live Query Stream.

05 · Monthly allowance and limit

Each index has its own monthly bandwidth from your plan. It starts again on the 1st of every month, you get an email at 90%, and an index over its allowance answers every request with 403 until it is back under. Details: bandwidth.

Read Full Answer

Solr Best Practices

Solr does not run out of memory because it is busy. It runs out because of what it was asked for: a page ten thousand results deep, a facet on a field that has to be un-inverted first, a query that returns every field of a thousand documents. This page is the list of the requests and settings that cost memory, what each one costs, and what to do instead.

A Solr node uses two kinds of memory. Only the left-hand side has a hard ceiling.

The guide, one page per topic

Where Solr memory goes

The JVM heap and the memory-mapped index: which one has a hard ceiling.

Ask for fewer rows and fields

Every returned document is read, decompressed, cached and sent.

Deep paging and cursorMark

The cost of a page grows with its offset. cursorMark keeps it flat.

docValues and the TextField trap

Facet, sort and group from disk instead of the heap, and the type that cannot have them.

Cache sizing

filterCache, queryResultCache and documentCache, sized against your document count.

Faceting, grouping and highlighting

What each one costs and how to ask for less.

Queries that fail on their own

Too many clauses, leading wildcards, regular expressions and other queries that throw.

Indexing without a memory spike

Batch sizes, commits and the searcher that every commit opens.

Never put binary data or base64 into Solr

Pictures, files and any base64 blob have no place in a search index.

Inline base64 images in indexed HTML

Pictures pasted into a CMS editor get indexed inside the page HTML.

N-gram fields belong on short text only

Partial matching that multiplies the index when used on long text.

Suggesters that rebuild on every commit

Autocomplete that reads the whole index on every commit.

Dynamic field explosion

Field names generated per site or environment, paid for in every segment.

When one document keeps crashing Solr

One oversized document that fails every indexing run.

CMS integrations that commit every second

Per-second commits from CMS modules and what they cost.

If you connect through a CMS

Most of the traffic we see is generated by a module rather than by hand, which means the fix is usually a setting in the module and not in Solr.

Drupal

Keep search_api_solr and the Opensolr module current — several releases have fixed query construction bugs that produced far heavier requests than intended. Check the enabled facets and the number of items per page before blaming the index.

WordPress

The plugin defaults are sane; the memory problems come from templates that request every field to render a result card. Trim the field list in the template.

Bots reach your search page too

A paginator that a crawler can walk will be walked, one deep page at a time. Rate limit the search path, or mark deep pages as not indexable.

What Opensolr does when it happens anyway

Automatic recovery

Every server is checked from outside itself. A failed check is retried ten seconds later, and if it still fails, the services on that server are restarted and the recovery is logged.

Query Analytics

Query volume, response times and the slowest queries per index: a deep paging loop or a runaway facet shows up as a shape, not as an outage.

Error Audit

Every Solr error of your index, parsed and searchable, so an exception at three in the morning is still there when you look for it.

Unusual traffic alerts

A daily check of the request log emails the owner and the team when an index sees deep paging, a sudden traffic spike, one address flooding it or a wave of rejected logins, with the request that triggered it.

The short version

Do	Because
Keep `rows` under 100 and always send `fl`	Every returned document is read, decompressed, cached and serialized.
Keep `start` under 50,000, and use `cursorMark` to export	The cost of a page grows with its offset: 74 ms at the start became 5,988 ms a million results deep (deep paging).
Put `docValues="true"` on every field you facet, sort or group by	Otherwise the column is rebuilt in the heap and stays there.
Never put `docValues` on a `solr.TextField`	The core will not load. Use a `string` copy or `solr.SortableTextField`.
Size caches against your document count	One filterCache entry can be one bit per document in the index.
Ask for the facet values you display	`facet.limit=-1` counts and returns every distinct value in the field.
Batch your indexing and commit on a schedule	A commit per document is a searcher per document.
Store only what you return	Stored fields are index size, cache size and bandwidth at the same time.

Read your own numbers first

The slow queries, the deep pages and the heavy responses of your index are in its analytics. Start there, then pick the page above that matches what you see.

Query Analytics Live Query Stream

Read Full Answer

Solr 9 Features and What's New

Apache Solr 9 is the release that put vector search inside Solr itself, and the release that quietly deleted several classes a working Solr 8 configuration still names. Those two facts are the whole story: it unlocked everything Opensolr does with AI, and it is the reason a config file that booted for years can refuse to boot after one upgrade. This page is the overview, with the Solr versions you can pick on Opensolr today; each part of the release has its own page.

Solr 9 in one picture. The bottom-left quadrant is the one most upgrade guides get wrong: those components were relocated, not deleted.

Solr 9, part by part

Dense vectors and the knn query parser

DenseVectorField and {!knn}: the release that let Solr match by meaning, and what that powers on Opensolr.

Everything else Solr 9 added

Java 11 and up, Lucene 9, certificate authentication, rate limiting, node roles, SQL, new stemmers, SolrJ on HTTP/2.

What Solr 9 removed and what only moved

Contribs became modules; DIH, Velocity and the old cache classes are gone. One table, with what to do for each.

Defaults that changed in Solr 9

The settings you never set that change under your configuration: caches, highlighting, boolean clauses, auth, docValues.

WHICH SOLR VERSIONS OPENSOLR RUNS TODAY

Straight answer, no marketing: the newest Solr you can select when you create an index on Opensolr is Solr 10.00, and vector search with hybrid ranking runs on every version from Solr 9.00 to Solr 10.00. Below is the whole version pool, live, grouped by what each band can do. What Solr 10 changes: How about Solr 10.0?

Current on Opensolr · dense vectors, hybrid search, AI features

10.009.609.409.00

Supported · no dense vectors, no hybrid search

8.608.118.00

End of life upstream · still orderable · hardware being retired

7.006.105.104.104.003.60

Legacy versions being orderable is not the same claim as legacy versions being supported forever.

Solr 3 through 7 are end of life upstream

No security patches and no bug fixes from the Solr project. Solr versions below 8.x are retired on Opensolr on 01/01/2027.

Legacy servers can still be selected

They appear on Add New Index and they run until the retirement date: Solr versions below 8.x stop on 01/01/2027.

Old hardware is being retired, with notice

If your index runs a version below 8.x, you get an email naming the affected indexes and the cutoff date. Move it before 01/01/2027.

There is no in-place upgrade

Lucene reads segments from one major version back and no further. A Solr 5, 6 or 7 index cannot be opened by Solr 9 at all. Upgrading always means a new core plus a full reindex from your source of truth.

Configuration moves. Data does not.

We convert schema.xml and solrconfig.xml for you. We never migrate documents, because the format makes it impossible. Reindexing is your side of the job, on every route.

Config migration is a paid service

Delivered in under four business hours; ask for the price. The old index keeps serving traffic in parallel the whole time.

Moving an old index to a current Solr

There is no in-place upgrade: a new index, a converted configuration and a reindex from your own source. The three routes, with the conversion tables: Solr migration. What Solr 10 changes: How about Solr 10.0?.

Read Full Answer