Single Realm with Query-based Sync vs. Multiple Realm Performance


#1

I’ve been reading about the latest Realm Cloud stuff and trying to wrap my head around all the permissions and subscription stuff (:exploding_head:) and I keep coming back to a question I’d like to ask here.

If I’m using Realm 3.x, when would I want to break up my app data into multiple realms vs. just restrict the availability of the data using queries? If my app data gets really large, will a single realm perform just as well as having the data sharded into multiple realms?

Maybe an example would help.

Let’s pretend I wanted to build something like Reddit on Realm Cloud. Should each subreddit be its own realm? Or should I just have a Subreddit class in the single, default realm and restrict its access based on the SyncUser (assuming Subreddits are private)?

Thanks in advance for your ideas and input. :slight_smile:


#2

@cliftonlabrum Great question - in general we are pushing everyone toward partial query-based sync. This is a more natural programming paradigm analogous to views in a SQL database or a REST request with a query parameter. In the future this will be the default way to sync whereas the full realm way will be the older more legacy method.

That said the full realm sync is older and more weathered so it is a bit faster today but we have a dedicated team just to query-based sync performance and they are making it better everyday. It helps that Realm is a column db and queries are blazing fast!


#3

Hi Ian,

If in the future I would like to migrate from full realm structure to query-based is that possible?
I mean technically.
I have many users , each got his own ~ realm.Reading your answer about the future - will there be some migrations script ? is it a best practice at all ? (Luckily I have for each class a unique GUID so shouldnt be a problem here)


#4

@yuvalkro Not sure about a migration script as part of the product - this is the first I am hearing of it. There is nothing wrong with using fully synced realms - it will be better for some use cases.