[lobster_johnson]

Is Vespa relevant if you're not into writing Java? I.e., can it be used as a black box similar to Elasticsearch?

From the repo, it looks like an absolutely huge, monolithic codebase. (It even bundles its own memory allocator!) Do you know if there are plans to break it up into smaller, more manageable pieces?

While I haven't looked at what's required to deploy this beast, operationally speaking, it sounds it might be daunting to run, and for non-"big data" applications might very well be overkill as an alternative to Elasticsearch.

[RealJon]

You don't need to plug in any Java code, you can use it with HTTP calls to read and write.

No plans to break it up into pieces (apart from already consisting of modules). It does one thing, it just happens to be a big thing :-)

If you have a mac of Linux box you can have it up and running in 10 minutes. Multi-node production deployments are no different because Vespa manages the nodes, not you directly.

[lobster_johnson]

From what I can tell from the documentation, schemas ("search definitions" in Vespa parlance) are stored as files that are part of the "application package" (which I don't know what is yet); it doesn't seem like you can make dynamic schema changes through a REST API, and some schema changes actually require search nodes to be restarted?(!) Doesn't Vespa have anything similar to the Elasticsearch mappings API for dynamically updating a schema?

This may be a difference in mindset, but we generally let apps define the schema, so it's in the developer's realm of responsibility, not an operational concern. We also have apps (currently using Elasticsearch) that manage the schema automatically, derived from a high-level application definition. With ES, the app creates a new index with new mappings, shovels data into the new index, and then activates the new index. But it uses the ES APIs to do this, and restarting anything is not on the table.