How we replaced Elasticsearch and MongoDB with Rust and RocksDB • Hacker News Board

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#21

Post by j_kao » Fri, Aug 08, 2025, 3:33 PM UTC

sophia01 wrote: post #3

They're not open sourcing it though?

It's a bit difficult at the moment, given we have a lot of proprietary data at the moment and a lot of the logic follows it. I'm hoping we can get it to a state where it can be indexed and serving OSM data but that is going to take some time.

That being said, we are currently working on getting our Google S2 Rust bindings open-sourced. This is a geo-hashing library that makes it very easy to write a reverse geocoder, even from a point-in-polygon or polygon-intersection perspective.

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#22

Post by everfrustrated » Fri, Aug 08, 2025, 3:36 PM UTC

dewey wrote: post #16

mikeocool wrote: post #8

Earlier quoted context omitted.

In my experience, the care and feeding that goes into an Elastic Search cluster feels like it's often substantially higher than that involved in the primary data store, which has always struck me as a little odd (particularly in cases where the primary data store is an RDBMS). I'd be very happy to use simpler more bulletproof solutions with a subset of ES's features for different use cases.

To add another data point: After working with ES for the past 10 years in production I have to say that ES is never giving us any headaches. We've had issues with ScyllaDB, Redis etc. but ES is just chugging along and just works. The one issue I remember is: On ES 5 we once had an issue early on where it regularly went down, turns out that some _very long_ input was being passed into the search by some scraper and ki…

How big is the team that looks after it?

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#23

Post by weego » Fri, Aug 08, 2025, 3:38 PM UTC

8n4vidtmkvmk wrote: post #12

pm90 wrote: post #7

Slightly meta, but I find its a good sign that we're back to designing and blogging about in-house data storage systems/ Query engines again. There was an explosion of these in the 2010's which seemed to slow down/refocus on AI recently.

Is it good? What's left to innovate on in this space? I don't really want experimental data stores. Give me something rock solid.

Agreed. The only caveat to that being a global rule is: 'At scale in a particular niche, even an excellent generalist platform might not be good enough'

But then the follow on question begs: "Am I really suffering the same problems that a niche already-scaled business is suffering"

A question that is relevant to all decision making. I'm looking at you, people who use the entire react ecosystem to deploy a blog page.

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#24

Post by j_kao » Fri, Aug 08, 2025, 3:39 PM UTC

brunohaid wrote: post #14

Bit thin on details and not looking like they’ll open source it, but if someone clicked the post because they’re looking for their “replace ES” thing: Both https://typesense.org/ and https://duckdb.org/ (with their spatial plugin) are excellent geo performance wise, the latter now seems really production ready, especially when the data doesn’t change that often. Both fully open source including clustered/sharded setu…

These are great projects, we use DuckDB to inspect our data lake and for quick munging.

We will have some more blog posts in the future describing different parts of the system in more detail. We were worried too much density in a single post would make it hard to read.

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#25

Post by mexxixan » Fri, Aug 08, 2025, 3:44 PM UTC

Would love to know how they scaled it. Also, what happens when you lose the machine and the local db? I imagine there are backups but they should have mentioned it. Even with backups how do you ensure zero data loss.

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#26

Post by itpragmatik » Fri, Aug 08, 2025, 3:46 PM UTC

dewey wrote: post #16

mikeocool wrote: post #8

Earlier quoted context omitted.

In my experience, the care and feeding that goes into an Elastic Search cluster feels like it's often substantially higher than that involved in the primary data store, which has always struck me as a little odd (particularly in cases where the primary data store is an RDBMS). I'd be very happy to use simpler more bulletproof solutions with a subset of ES's features for different use cases.

To add another data point: After working with ES for the past 10 years in production I have to say that ES is never giving us any headaches. We've had issues with ScyllaDB, Redis etc. but ES is just chugging along and just works. The one issue I remember is: On ES 5 we once had an issue early on where it regularly went down, turns out that some _very long_ input was being passed into the search by some scraper and ki…

how many clusters, how many indexes and how many documents per index? do you use self hosted es or aws managed opensearch?

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#27

Post by dewey » Fri, Aug 08, 2025, 3:47 PM UTC

everfrustrated wrote: post #22

dewey wrote: post #16

Earlier quoted context omitted.

To add another data point: After working with ES for the past 10 years in production I have to say that ES is never giving us any headaches. We've had issues with ScyllaDB, Redis etc. but ES is just chugging along and just works. The one issue I remember is: On ES 5 we once had an issue early on where it regularly went down, turns out that some _very long_ input was being passed into the search by some scraper and ki…

How big is the team that looks after it?

Nobody is actively looking after it. Good alerting + monitoring and if there's an alert like a node going down because of some Kubernetes node shuffling or a version upgrade that has to be performed one of our few infra people will do that.

It's really not something that needs much attention in my experience.

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#28

Post by dewey » Fri, Aug 08, 2025, 3:52 PM UTC

itpragmatik wrote: post #26

dewey wrote: post #16

Earlier quoted context omitted.

To add another data point: After working with ES for the past 10 years in production I have to say that ES is never giving us any headaches. We've had issues with ScyllaDB, Redis etc. but ES is just chugging along and just works. The one issue I remember is: On ES 5 we once had an issue early on where it regularly went down, turns out that some _very long_ input was being passed into the search by some scraper and ki…

how many clusters, how many indexes and how many documents per index? do you use self hosted es or aws managed opensearch?

12 nodes, 200 million documents / node, very high number of searches and indexing operations. Self-hosted ES on GCP managed Kubernetes.

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#29

Post by binarymax » Fri, Aug 08, 2025, 4:06 PM UTC

itpragmatik wrote: post #26

dewey wrote: post #16

Earlier quoted context omitted.

To add another data point: After working with ES for the past 10 years in production I have to say that ES is never giving us any headaches. We've had issues with ScyllaDB, Redis etc. but ES is just chugging along and just works. The one issue I remember is: On ES 5 we once had an issue early on where it regularly went down, turns out that some _very long_ input was being passed into the search by some scraper and ki…

how many clusters, how many indexes and how many documents per index? do you use self hosted es or aws managed opensearch?

Lots of other options here if you don't like managing. You can use Elastic cloud, Bonsai.io, and others

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#30

Post by j_kao » Fri, Aug 08, 2025, 4:09 PM UTC

kosolam wrote: post #15

Side note 1: ES can also be embedded in your app (on the JVM). Note 2: I actually used RocksDB to solve many use cases and it’s quite powerful and very performant. If anything from this post take this, it’s open source and a very solid building block. Note 3: I would like to test drive quickwit as an ES replacement. Haven’t got the time yet.

1 - I think if we were sticking with the JVM, I do wonder if Lucene would be the right choice in that case

2 - It's a great tool with a lot of tuneability and support!

3 - We've been using it for K8s logs and OTEL (with Jaeger). Seems good so far, though I do wonder how the future of this will play out with the $DDOG acquisition.