Amgix Now is Here
This post originally included Amgix Now benchmarks, they have been moved into a serparate post
Amgix Now is the newest member of the Amgix family, and it's available today. This post will explain what Amgix Now is, why we built it, and how it fits into Amgix family.
What is Amgix Now
Amgix Now is a high-performance hybrid search engine. Unlike Amgix, which is designed to be a distributed modular hybrid search system, Amgix Now is built as a single Rust binary that delivers Amgix search features with a focus on search relevance, high throughput and low latency.
docker run -d -v <path-to-data>:/data -p 8235:8235 amgixio/amgix-now:0
For GPU-accelerated hybrid search use amgixio/amgix-now:0-gpu image.
The same API as Amgix: Getting Started
Why We Built it
It started as an experiment: what would happen if we took Amgix, stripped out all the cluster communication and coordination layers and implemented it as a stand-alone hybrid search engine, in Rust?
WMTR and other built-in tokenizers were already implemented in Rust. At first, we ported basic API endpoints, collection and document processing logic, supporting database functionality and minimal internal coordination logic.
We ran some tests and were impressed by the initial performance indicators. We also realized that for many use cases, a simple reliable fast hybrid search engine is all that is needed, and if it can handle a decent amount of load, you may never need to upgrade to anything more advanced.
At this point, it became not "if" but "how soon" we can build it.
We ported the rest of the API endpoints, internal logic, hybrid search and embedding pieces.
After the first milestone of passing all the Amgix API integration tests was achieved, we focused on running tests, tweaking, tuning and optimizing internal architecture and performance.
The result is the Amgix Now we have today.
So in a way, it was never about "why", it kind of demanded itself into existence. We couldn't help ourselves.
Where Amgix Now Fits in Amgix Family
The table below explains some of the differences and trade-offs of using Amgix Now, Amgix One, and full Amgix cluster.
| Amgix Now | Amgix One | Amgix | |
|---|---|---|---|
| Hybrid search | engine | system | system |
| Single container | ✓ | ✓ | |
| Async ingestion pipeline | ✓ | ✓ | |
| Dashboard & metrics | ✓ | ✓ | |
| PostgreSQL/MariaDB | ✓ | ✓ | |
| High availability | limited* | awkward** | ✓ |
| Modular scaling | ✓ | ||
| Model self-orchestration | ✓ | ||
| Throughput | high | medium | scales with cluster |
| Latency | lowest | medium | medium |
| Operational complexity | lowest | medium | highest |
- * Amgix Now can be configured as a primary/fallback behind a proxy and a shared external Qdrant instance
- ** Multiple Amgix One instances can be deployed with external RabbitMQ and database instances, but it's awkward and better served by a full-scale Amgix cluster deployment
Some key points:
- the API is identical between Amgix Now and Amgix (with the exception of metrics and a couple of async queue endpoints that are not implemented)
- Qdrant is the default and only storage supported in Amgix Now
- Like Amgix, Amgix Now is not tightly coupled with a backend database. You can point Amgix Now at an external Qdrant instance.
- All document upsert and delete endpoints are synchronous (there is no async ingestion pipeline or queue)
- Documents are automatically deduplicated on upserts and internal locking preserves write atomicity (just like Amgix)
This makes for an interesting upgrade story. Because the API is identical and storage is identical (if you use Qdrant) you can switch from Amgix Now to Amgix One or full Amgix by simply mounting the same storage directory and starting a different version of Amgix. No application changes are required. You can go from Amgix Now to Amgix One and back again by simply stopping one container and starting another.
If you are curious about Amgix Now performance, see Amgix Now benchmarks.