How does it compare to meilisearch?

I would pay $5 to have every one of these projects stop saying "alternative to ElasticSearch" unless they implement the ES API (as https://github.com/zinclabs/zinc at least claims) because if one just wanted some schemaless full text searching wizardry, there are about 10 of those projects. If one is trying to replace kibana or the damn near infinite log gathering tools that target ES, Sonic and Melisearch and and and are not going to get it done

q.v. https://github.com/zinclabs/zinc/blob/v0.3.6/docs/swagger.ya...

I mean, Elasticsearch does a whole lot of stuff, and I wouldn't expect a 'super light alternative' to do everything Elasticsearch does. If I were still dealing with ES, I'd look to see if it did the small section of stuff in my use case and if the API was reasonable and if it had a sensible operational profile and if it hit all those points, I'd try to use it, because I sure wasn't happy with ES.

Note that a reasonable API doesn't require it to match the ES API, and if I'm feeling really bitter, doesn't even include the ES API.

Now when someone says they're a replacement that's a lot more specific; I see ZincSearch makes a qualified claim of that form, if that's not accurate, then yeah, it's worth complaining. But lots of things are alternatives without being replacements (and really replacement doesn't always have such a narrow meaning either, kind of depends on usage)

That's _exactly_ what I'm trying to build, and you don't have to pay anything. I was frustrated with what I thought was a poor interface for Kibana, and having to deal with schema for Elasticsearch, so I built log-store. I appreciate any feedback!

I initially thought you were the author of Zinc, but based on your comment history you're trying to build a logging SaaS replacement or something, which based solely upon its documentation is ALSO not ES API compatible, so I don't know how to interpret your reply

I guess I misread your comment... my apologies. What I'm building is more a replacement for Splunk: on-prem log analytics. As you point out, it is not compatible w/Elasticsearch in any way.

> What I'm building is more a replacement for Splunk

Wow, you really are swinging for the fences, then. I wish you all the best, because running Splunk is terrible, and ripe for replacement, but its search featureset and UX are massive so I hope you are laser focused on who the target audience is for your product

Thanks! Would love to know more about your experience running Splunk... Can I reach out to you?

Looking for some small niche... Industrial, automotive, even garbage truck monitoring :-) I'm not looking to build a massive public company or anything either... More a lifestyle business. We'll see.

Sure, just submit a "Ask HN: What is your experience running Splunk?" and point me to it. I'm sure you'll get all kinds of horror stories aside from mine

I asked a slightly different question, but I'd love to hear about your experience running Splunk: https://news.ycombinator.com/item?id=34412176

> I was frustrated with what I thought was a poor interface for Kibana

I can't think of a better/more well done user interface than Kibana. Am I missing something?

The interface (GUI) is OK (and looks better than mine honestly), but the usability isn't great. The query syntax is tough to grok IMO. Using the sample dataset it took myself and a friend who knew Kibana like 5 minutes to figure out how to make a pie chart of the various OS types. It's probably that we're just dense and don't know what we're doing, but with log-store you just click the pie chart icon next to the field, and it will update the query and render the chart. I think that's easier to use.

Is source available? Or binary only?

Only binary. Ultimately I would like to sell it, but just looking for feedback at the moment.

How often do people use Elasticsearch without Kibana? I would use something that empowers Kibana's amazingly powerful UI, but like you called out, that would need to be "binary" compatible since Kibana is expecting the Elasticsearch API.

> (Kibana is not supported with zinc. Zinc provides its own UI).

Last place I worked used ES alone to power a complex search system. No Kibana. We were running about 100 instances with about a petabyte of data.

We're going the same route in my new place. If you want full text search with scalabilty and durability (and automated lifecycle management, these days) ES is still really the only game in town (not counting OpenSearch, as it's the same thing).

previously: https://news.ycombinator.com/item?id=33315237 (the blog post has also gotten some submissions, but nothing as compared to the github submission)

Hi, this seems like a really cool project! Given your use of rust, have you considered providing the option to run this as an embedded datastore, like you might use sqlite?

Might bring more users onboard, for the better CI/testing ergonomics. Thanks!

Is it ready for GraphQL Federation?

I was looking at the Github repos for Sonic, and a PHP library for working with it: https://github.com/ppshobi/psonic/blob/master/api-docs.md and I'm scratching my head over: what's the difference between the popping and flushing operations?

Specifically, there's a "pop" method which: "pops an item out of index" and a "flusho" method which "Flushes the indexed text from an objects". They kind of sound awfully similar and take similar args.

Otherwise it all looks pretty straightforward - just that one small conceptual thing might be explained a bit more in the docs.

I use postgres fulltext search instead and it works great. Plus, one less dependency.