Can ArcadeDB replace Redis for Rails caching? How about for Sidekiq?

[brandonzylstra]

I'm interested in adding ArcadeDB to a Rails app, and (if everything works out well) gradually moving more and more to Arcade.

1. First implement caching with Arcade instead of Redis.
2. If caching works well, move Sidekiq background jobs over to Arcade, and kick Redis to the curb. (Or I might migrate all background jobs to GoodJob first. But either way I could remove Redis at this point—not because I dislike it, but just because it's a simple starting point to moving to Arcade.
3. Then there is a feature that I need to implement which would be much better with a Graph database (one of the main reasons I'm interested in Arcade) than if I implement it with Postgres using joins. Once I've got Arcade in place and it has proven itself reliable, it would make sense to build this.
4. Then, if everything goes well with that, it might even make sense to move off of Postgres entirely, and do everything with Arcade.

Is all of this possible and reasonable?

• Does Arcade implement enough of Redis' features to allow it to be a drop-in replacement for Sidekiq and Rails caching?
• Does it support JSONB columns over the Postgres wire protocol? Does it support materialized views?
• Is there any hidden "gotcha" that I might encounter?

[lvca]

The idea makes total sens: one multi-model database instead of N.

1. About Redis, you can find the supported commands on the official docs: https://docs.arcadedb.com/#Redis-API. Please let me know if you need support for additional commands.
2. JSONB in Postgres, AFAIK, doesn't duplicate property names, so it's not space efficient like MongoDB or ArcadeDB where we the comparable type is EMBEDDED. You can store embedded documents recursively to infinite depth. Materialized views are not supported, sorry. Usually you use them because the cost of JOIN is too high, so you create a flat view of part of your domain. With a native GraphDB, like ArcadeDB, you don't need it, because the cost of resolving a relationship is a fraction of a RDBMS
3. I don't see any issue with this idea

[brandonzylstra]

Thanks for the response!

I don't see any issue with this idea

It's very helpful to know this before I start! 👍

JSONB in Postgres, AFAIK, doesn't duplicate property names, so it's not space efficient like MongoDB or ArcadeDB

did you mean to say JSONB doesn't DE-duplicate property names? I would expect more space efficiency from DEduplication than from allowing duplication.

Materialized views are not supported, sorry. Usually you use them because the cost of JOIN is too high, so you create a flat view of part of your domain. With a native GraphDB, like ArcadeDB, you don't need it, because the cost of resolving a relationship is a fraction of a RDBMS

Okay that's very good to know. Would I need to change the structure of my data in order to benefit from the speed of ArcadeDB, or would that happen invisibly to me—while I still use JOINs in my SQL but Arcade handles them differently under the hood?