&gt; it looks like a web app would have to be rebuilt from the ground up to fit that model.<p>Not at all! The app market is full of apps that were not originally written for Sandstorm:<p><a href="https:&#x2F;&#x2F;apps.sandstorm.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;apps.sandstorm.io&#x2F;</a><p>Examples: Wekan, Etherpad, Rocket.Chat, EtherCalc, draw.io, Gogs, Dillinger, NodeBB, EtherDraw, ...<p>It turns out that converting a web app to Sandstorm is mostly deleting code. You delete your user management, your collection management, your access control, etc. What you have left is the essence of your app -- the UX for manipulating your core data model, of which you now only need to worry about one instance.<p>&gt; doesn&#x27;t that mean you also have to start a process every time a user opens a document?<p>Most apps we&#x27;ve encountered only take a couple seconds to start. But we&#x27;re working on a trick where we snapshot the process after startup and start each grain from the snapshot, thus essentially optimizing away any startup-time slowness.<p>&gt; How do you handle indexes, views and collections over a large set of data objects?<p>Sandstorm is (currently) designed for productivity apps, not for &quot;big data&quot; processing. The data within a single grain is usually small. That said, you can run whatever database you want inside the grain.<p>(I&#x27;m the tech lead of Sandstorm.)