instacart/makara

Looking for maintainers

Opened this issue · 8 comments

drdrsh commented

We are looking for maintainers to oversee the support and development of Makara. We are no longer using Makara at Instacart and we are unable to dedicate the time and resources to maintain it.

If you or your company/group are interested in maintaining Makara, please leave a note on this issue.

matthewford commented

@drdrsh have you moved away from mysql or using something else?

drdrsh commented

We are mainly on PostgreSQL.
We built a drop-in replacement for Postgres Makara in-house.

ali-alakbar commented

I am interested

yboulkaid commented

Thanks for the transparency about not using Makara at Instacart anymore.

Would it be possible to give more details about why you went with an in-house solution? Are there any known design pitfalls with Makara that were hard to change? This might be useful as a "post mortem" for people stumbling upon this or who want to take over the gem :)

mateuscruz commented

Hi everyone. For people looking for a lightweight version to allow automatic connection switching between primary and replica databases, without the need for multiple pools, load balancing, etc, that also works with Rails 7.0 or greater native multiple database setup, I built a new gem for that.

You can find it here: https://github.com/Nasdaq/active_record_proxy_adapters

It is heavily inspired by Makara (thank you @drdrsh and the whole Instacart team for the great work on this), but does not require a custom database.yml format, and works natively with rails ActiveRecord::Base.connected_to(role: reading|writing) blocks.

We do load balancing of replica requests outside of the application domain, which I believe is what Instacart is now doing using pgcat (which Mostafa also maintains), which he mentioned in his keynote at Rails World 2024. So the absence of a Rails managed database pool of replicas is not an issue for us.

It is still limited in functionality and we only support Postgres as of now (but PRs are welcome for other RDBMSs).

There are some gotchas you need to be aware of (like replication delays in the setup of a background job, for example), but those can be addressed with some custom .connected_to wrappers.

Feel free to try it out and let us know of any issues you might have. We've been using it in Nasdaq for a few months now and it's worked well in our setup.

mateuscruz commented

@yboulkaid this is what you're looking for: https://www.youtube.com/watch?v=aPsstRiNocY

  • 👍1
  • ❤️1
northeastprince commented

Is Active Record's new built-in functionality not sufficient?

  • 👍1
mateuscruz commented

@northeastprince if you only need automatic connection switching on the HTTP request layer, then yes. Otherwise, it isn't.