IDK about this angle, just because elasticsearch / SQL has fucky syntax doesn't mean that crafting queries in code is something we wanna say goodbye to?
I like what Google Malloy has done, it made writing things in code enjoyable by reinventing the syntax and language, but keeping it compatible with existing tech.
Otherwise this is cool! I found it daunting as a newcomer to search thinking about optimizing search and making sense of how users use it.
But even with elasticsearch, it was not that hard to craft queries to do a faceted search and it was cheap and easy to setup, so the value I see is more in the analysis. And if you're going beyond a faceted search with basic group and / or logic, then isn't vector searches the way to go anyway?
I'm probably missing something!
Analytics: our painpoint with a few other search solutions was a lack of out-of-the-box insights for user behavior and common searches. We’re addressing this with Searchbase
What does "real time" means, are we talking about minutes or seconds?
Finally, how does it work for data that needs to be joined, should I create prejoined tables locally?
Maybe the AI revolution placed convenience over data ownership, but there's no way I'm giving full read access to my databases to a third party.
I’m very open to the idea of an on-prem version of Searchbase as an option in the future! We decided to start with a cloud version for our MVP to enable users to get started with Searchbase in a few minutes.
As for sharing DB credentials, I get the concern. “Subscribing” to your database is meant for developer convenience. But if there’s demand, we’d also like to support the traditional ETL method of “manually bulk uploading” :)
Benchmarks: this is a big one! We have some initial data that shows we’re comparable to elastic for fuzzy-search at medium scale. However, one of our value-propositions is out-of-the-box semantic search, so we’re working on a blog post with the full benchmarking story.