60
34 Comments

Show IH: We built an Open Source alternative to Algolia & Elasticsearch

  1. 7

    Hi IndieHackers,

    A friend and I have been working on an open source and lighter-weight alternative to Algolia and Elasticsearch - we call it Typesense: https://github.com/typesense/typesense

    We've been working on it for couple of years now and after several iterations over the years, we're finally ready to start talking about it more widely!

    In short, if you're looking to add search to your site or app and don't want to worry about cost (Algolia) or waste time figuring out how to operate a complicated piece of software (Elasticsearch), then Typesense could be a good alternative for you. We optimize for developer happiness and ease of use, while not compromising on performance.

    A couple of key features that work out-of-the-box:

    • typo tolerance
    • filtering
    • faceting
    • sorting
    • grouping / distinct
    • client-scoped keys
    • result curation
    • raft-based clustering for high availability

    I'd love to hear your thoughts & feedback 🙏

    1. 1

      This comment was deleted 7 months ago.

      1. 1

        @jkristobans Yes it definitely can. Now, given that all content is on one long page in your case, you want to add fragment identifiers to your links (#resource-xyz) when you index them and then when people click on the result links the browser should just scroll them down to the appropriate point in the page.

        1. 2

          This comment was deleted 7 months ago.

  2. 2

    I tried your demo in typesense.org
    I entered thedavincicode, the davincicode, the da vincicode, davinci, the davinci,
    but the da vinci code was not in results!!!

  3. 2

    It looks great !!, but it seems like it only supports python for now. Is that something that is going to change anytime soon, or did I get it all wrong?

    1. 2

      In addition to a Python client library, we do have JS and Ruby client libraries, with a PHP library in the works.

      You’ll find them pinned here: https://github.com/typesense

      Also, for languages that we don’t yet have a client for, you can use our http api to make calls from any popular http client libraries in your language.

  4. 2

    That's interesting and congrats.
    My only question would be: what do you mean exactly by "don't worry about cost"?
    How does your cloud service compare to Algolia? What's the order of magnitude of the savings?

    1. 3

      @sowenjub The open source version is full-featured and free to run on your own infrastructure.

      With our cloud hosted offering (just launched the public beta last week) (we run the same open source version), price depends entirely on the size of your dataset and cluster configuration, starting at $14.40 a month at the lowest end.

      We wanted our prices to be reasonable and affordable for every type of usage from indiehackers like ourselves, to fast growing companies to large enterprises. So we decided to charge by the hour (cluster runtime) plus bandwidth, similar to how AWS charges for EC2 / RDS instances. Different cluster configurations have different hourly prices (https://cloud.typesense.org/pricing/calculator).

      With Algolia, from what I've seen and heard, their prices seem to not scale well when going from their published pricing plans to their "Contact Us" enterprise plans. So for growing products, it's not uncommon to suddenly see a 5x-10x increase in price when going from the most expensive standard plan to an enterprise plan.

      In general, our cloud pricing is roughly 40-60% lesser than Algolia's enterprise offerings, which we hope makes it a very attractive SaaS alternative, if the the fact that we're open source and free to run yourself (and on your local development machine) isn't already!

      1. 1

        @jasonbosco what are the minimum requirements(hardware) to run typesense?

        1. 1

          @ayyappa99 You'd at least need 2vCPUs. The amount of RAM you need is completely dependent on the size of your dataset. The Typesense process itself only takes about 19MB of memory, but then since Typesense is an in-memory search engine, all data you index is stored in memory. So you need sufficient RAM to hold all your data in memory.

          1. 1

            I'm currently reviewing if its worth to self host or go with cloud option. Can you please let me know at what point cloud offering makes sense? Is it possible to self-host for a lesser price compared to cloud option. I understand cloud option comes with more benefits but until we have good traffic we can't spend on it.

            1. 1

              Essentially, if you already have an existing infrastructure where you manage servers / VMs / containers, then adding Typesense into the mix and self-hosting should be pretty easy.

              But if you don't have an existing VM / container footprint, then using the Cloud version would save you effort. Point and click and you get a production-grade cluster.

              1. 1

                Thanks for sharing! I will give a try.

    1. 1

      Thanks @jatin! If you get a chance to try it out, I'd love to hear your feedback.

  5. 2

    Hey, it looks very interesting. I haven't had the chance to explore it fully but I'm curious do you provide the use custom styling for the search component?

    1. 1

      @HumzaKhan Yes! Since we offer an adapter for InstantSearch.js [1], you can use all the styling options that InstantSearch.js gives you. You'll find the documentation here: https://www.algolia.com/doc/guides/building-search-ui/widgets/customize-an-existing-widget/js/#css-class-override

      [1] https://github.com/typesense/typesense-instantsearch-adapter

  6. 1

    Hi @jasonbosco. I would like to write a blog post about this. Are you up for the a few short questions?

    1. 1

      @ditData Thank you! Yes, I’m up for it. My email is in my profile.

  7. 1

    The recommendation in your typesense cloud is 2-3x memory of dataset. Does that mean I can't split indexes per customer/tenant and just be using the same instance to do searches? or is that available if I host my own instance?

    1. 1

      @altlimit

      Does that mean I can't split indexes per customer/tenant and just be using the same instance to do searches?

      You can definitely index data from multiple customers (of yours) in a single cluster. In fact, you can even index data from multiple customers in a single collection (index) and then use the client-scoped keys feature [1] to setup ACLs based on filters, to determine which customer can access which subsets of the index.

      [1] https://typesense.org/docs/0.15.0/api/#generate-scoped-search-key

      We run the same open source version in the cloud offering, so you can also do this when you run Typesense on your own servers.

  8. 1

    Congrats! Looks awesome! Will definitely try it out :)

    1. 1

      Thanks @greengallop23! I'm all ears for feedback. Let me know!

  9. 1

    Is this your product?

  10. 0

    You had me at "open source"

  11. 3

    This comment was deleted 3 years ago.

    1. 1

      I am interested in knowing your experience with MeiliSearch. I started with it during its early days but dropped it very soon afterwards for Algolia for a search component.

      1. 3

        @joyed You should find this interesting: I built an adapter for Instantsearch.js so you can use the same frontend search components that Algolia offers, but have the queries be sent to a Typesense server instead of Algolia:

        https://github.com/typesense/typesense-instantsearch-adapter

        1. 1

          @jasonbosco Thanks for the tip! I don't use any of Algolia's UI components, just their API. I found it super easy to get started with, as opposed to Elasticsearch (which I also use for another project btw).

          I plan to try Typesense out soon. The one thing that gets me worried is the robustness of new solutions. That's the reason I left Meilisearch. Following the steps on their site simply didn't work for me. At the point, I decided it's not worth taking the risk and put something into production with it. But looks like they have ironed out those frills and you have got a good maturity on your product as well. Thanks again!

          1. 2

            @joyed I hear you on production-readiness. We've been working on Typesense for a couple of years now and have resisted the urge to talk about it broadly until recently, only because we wanted to make sure we've first ironed out known issues and we know that it works reliably, both of which we've addressed now. So hopefully that allays some concerns!

            If you find anything off in the docs, please please let me know! I want to address it right away.

      2. 1

        This comment was deleted 3 years ago.

        1. 2

          @tejpochiraju I mentioned this in another comment, but I think you’ll find this interesting: I built an adapter for Instantsearch.js so you can use the same frontend search components that Algolia offers, but have the queries be sent to a Typesense server instead of Algolia:

          https://github.com/typesense/typesense-instantsearch-adapter

          This way, you get to take advantage of all the flexibility and power instantsearch.js offers you without having to build and maintain your own search component library.

  12. 0

    This comment was deleted 3 years ago.

    1. 4

      Hi @anilkilic, I should have mentioned, we intended Typesense to be a lighter-weight alternative to Elasticsearch, if you don’t need to search through petabytes of data (like logs).

      From my experience using ES at past companies, if dealing with the JVM itself isn't enough of an overhead at small scale, at even reasonable scale you typically need a team of engineers paying close attention to your ES cluster performance and regularly keep tuning it. With Typesense our goal is to keep ops overhead super low. It is a single self-contained binary that just works. We also have a docker build.

      ES also has a few thousand configuration parameters for you to tweak to get to your ideal setup. With Typesense we aim to provide an out of the box experience with sane defaults, so things just work well for majority of use cases.

      So simplicity, developer happiness and ease of use are what we optimize for, while not compromising on performance, compared to ES which is quite a large and complicated piece of software to operate and scale.

      1. 1

        This is so true! Even for simple usages ES mandates that you have someone well-versed in it on your team. Else you are going to have surprises.

    2. 4

      I can't believe this has 5 upvotes. It's such a rude comment too, to just link to a huge monolithic software built by a VC funded company.

      Elasticsearch is not an easy software to run and it's not cheaper either.

      Do some research before making a low effort snarky comment like this.

      1. 0

        This comment was deleted 3 years ago.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 47 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 27 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments How I Launched FrontendEase 13 comments