Frequently asked questions

How is Searchcraft easier to manage than other search providers?

Low setup.

We configure and tune the search engine with sensible defaults that work well. If you do need to make adjustments to your field weightings this can be accomplished through the dashboard UI, no developer is needed. For custom term synonyms and stopwords those are also managed through the dashboard, no developer involvement is needed to make those adjustments.

This frees up your engineering team’s time to focus on building your product instead of building search.

For a detailed comparison of Searchcraft to other search providers see our comparisons page.

Why do applications need search?

Once your application has data of a significant size it becomes difficult to sort through this information efficiently. While databases are amazing at storing and relating data their main focus is not for the performant searching of data. For this you need a purpose built search layer.

Is Searchcraft memory safe?

Memory safety is a high priority for Searchcraft. Our search engine and back-end cloud services are written in Rust and is memory safe by design and we approach all of our SDKs and CMS integrations with a focus security-first mindset. We believe this focus on memory safety is a key differentiator for Searchcraft.

Why use Searchcraft Cloud over self-hosting an open source solution?

While open-source software is free, running search itself is not. There is a cost for hosting the infrastructure and engineering costs to for setup, integrate with your application and maintain the cluster. With Searchcraft Cloud the overall cost is much lower. You just add a few lines of code to your application and you are ready to go. Because our infrastructure costs are lower we can pass those saving to customers. Elasticsearch in particular is notoriously difficult to configure and tune properly and requires ongoing engineering hours to maintain. Elasticsearch has roughly 3000 configuration parameters that need to be tuned for your specific use case. On top of that you need to fine tune the JVM configuration. By building in Rust we avoid the JVM configuration completely. Since Searchcraft has a focus on app and website content search instead of trying to do everything we are able to have an opinionated approach with sensible default configurations to provide the best experience.

If you are managing your own Elasticsearch cluster in the cloud you also need to configure discoverability rules between the nodes so they can talk to each other on top of security rules for ingest and Kibana access. Searchcraft Cloud has a easy to manage allow-list and access key system for external access and secure communication between cluster nodes is handled for you.

But I need an integrated, on-prem solution

For applications where Searchraft Cloud is not a good fit we offer a self-hosted option with optional support plans. The self-hosted option is a great fit for on-premise deployments or for customers who need to manage their own infrastructure but it does require more engineering effort to get up and running. However, you do still benefit from lower configuration and tuning requirements with less memory and CPU requirements due to the Rust-based architecture.

Why did you choose to build a new search product?

Search is an evergreen problem. As soon as any dataset reaches a threshold in size it will need to be searchable. Most of the current players out there are still building off of old technology, Lucene, which is over 25 years old and not lot of new players enter the space because search is a difficult problem to solve. We believe we can make the developer experience of integrating search easier while offering a product with a more modern technology stack.

With the rise of LLMs is keyword search still relevant?

We are currently in a hype cycle around LLMs. To put it in perspective when NoSQL solutions came onto the scene, it was the next big thing in databases but it didn’t kill SQL. Postgres is doing fine. It’s a matter of choosing the right solution for the problem. Keyword searching is exact, scales better with lower cost and latency. Vector searches, which is what LLMs use, return results based on proximity and semantic similarity, which is not always accurate. There is a higher cost to scale and run LLMs and from a climate sustainability perspective, the power consumption has environmental implications. For an application that needs accuracte results with high-performance, full-text keyword search is a better fit.

Does Searchcraft support incremental indexing?

Yes. Payloads may be broken up into multiple requests. You may send a batch of documents or single documents. In general its best to consider network conditions, average individual document size and if there are overall limitations with your request library in regards to maximum payload size. In general we recommend limiting each ingest request to 50,000 or less documents at a time or around 150MB in size. This is a soft recommendation that may vary based on the size of the individual documents. When ingesting a large number of documents it is better to send them in batches of multiple documents rather than one at a time.

What are the available integrations and SDKs?

Searchcraft is a new product and we are working integrations for the most popular CMS platforms and SDKs for the most popular frameworks. Our currently available SDKs may be found in our SDK section.

If you are interested in an SDK or CMS integration that is not yet supported, please reach out to us.

How can I update already indexed documents?

Data in Searchcraft is immutable. To edit a document, the document needs to be deleted and reindexed.