Elasticsearch workload evaluation

Evaluate support-event search and investigation

Search shipment reports, filter by order and inspect the observations and linked records behind a support incident.

Components that could move
The duplicate support-search index, indexing pipeline and separate source lookup, once relevance and freshness pass.
What stays in your stack
Your support application and any workloads needing Elasticsearch DSL, analyzers, Kibana or plugins.
How to test it
Run the matching quickstart in a free workspace alongside your existing system. Compare the records, relevant operations and latency before moving this workload.

One workload, using Jylus HTTP APIs. Existing drivers, query languages and connectors are not assumed compatible. Keep production traffic in place during evaluation.

Current architecture

  1. Application events → search indexing pipeline → Elasticsearch
  2. Support API → search results + source-record lookup
  3. Application code → timeline and linked-record assembly

Proposed Jylus architecture

  1. Application events → Jylus ingest
  2. Support API → Jylus search/query/analyze
  3. Jylus → ranked records + bounded history + explicit relationships
Compatibility, migration and verification requirements

What can disappear after verification

For a passing support-search workload, the duplicate search index, its indexing pipeline and a separate source lookup may be removable. The search query and result rendering in your application must be adapted.

What remains

Keep workloads that depend on Elasticsearch analyzers, DSL, aggregations, Kibana, plugins or specialized relevance settings until each is separately supported and tested. Both acceptance and search visibility must be measured; the Elastic refresh contract does not automatically carry over.

How to move a sample

Replay source JSON events rather than copying an Elasticsearch index. Map timestamps and namespaces explicitly and translate each required search/filter to the documented Jylus API. There is no general Elasticsearch DSL compatibility promise.

How to verify the result

Create a labelled incident query set. Compare relevant IDs, omissions, ranking, filters, time bounds, freshness and p95 latency. Do not retire the existing index on the strength of the four-record example alone.

Example architectures for one workload; compare your actual components. Scope checked against documented product surfaces, 21 October 2026. Elasticsearch search-visibility documentation. This is not a blanket feature or performance comparison.

Know the operating boundaries before you switch.

Data behaviour
JSON events over HTTPS, source-ID and time queries, bounded history and analysis. The records quickstart uses those ID/time filters; verify every other required business-field filter on your workload. Acceptance is separate from query readiness: verify the receipt and read back IDs. Corrections are new linked events. This is not a claim of multi-record ACID transactions or existing database-driver compatibility.
Retention
Choose expiry or no expiry in workspace settings. Expiry removes eligible records; it is not just a search filter. Keep an independent source copy for your evaluation.
Access controls
Workspace isolation, scoped read/write API keys, key revocation, team roles and account MFA. Keep secret keys on your backend. Security details.
Export and recovery
Read source records through bounded query windows and save them in your own archive. The quickstart saves a receipt and responses locally. A one-click full-database export, customer point-in-time restore, three-machine deployment or contracted recovery objectives are not included promises; agree requirements with support before migrating.
Limits and cost
Free Developer includes 1 GB. At the storage cap, new ingest pauses; retained data is not deleted and permitted reads continue. Paid expansion needs an available billing option, your approved rate and spending cap. Buying storage preserves throughput and query limits. Compare plans.
Support
Use support@jylus.ai for evaluation questions. Confirm plan support, SLA, regional capacity, recovery and migration arrangements before moving critical traffic. API limits and retry behaviour.