Indexer 2.x to 3.x Migration FAQ.

README.md

@@ -287,4 +287,6 @@ For all other transaction queries, results are returned oldest first. This is be
 
 If you were previously using Indexer 2.x you will need to reconfigure your deployment to include [Conduit](https://github.com/algorand/conduit). The data loading component has moved from Indexer 2.x to Conduit.
 
-[Additional details found here.](https://github.com/algorand/conduit#migrating-from-indexer-2x)
+See the [Indexer 2.x to 3.x Migration FAQ](docs/MigrationFAQ.md) for common questions.
+
+[Additional about configuring Conduit can be found here.](https://github.com/algorand/conduit#migrating-from-indexer-2x)

docs/MigrationFAQ.md

@@ -0,0 +1,30 @@
+# Indexer 2.x to 3.x Migration FAQ
+
+## Does Indexer 3.x change the REST API?
+
+No. The Indexer 3.x REST API is fully backward compatible with Indexer 2.x. No change is required in applications or the Algorand SDK.
+
+## Can the node used by Conduit be used to submit transactions?
+
+No. The "follower" node used by Conduit is not a general purpose node and cannot submit transactions to the network. It has disabled many services compared to other types of nodes.
+
+## What are the resource requirements for Conduit and Indexer 3.x compared to Indexer 2.x?
+
+The compute requirements are similar. With Conduit and a "follower" node performing a task previously handled by Indexer 2.x and an "archival" node.
+
+The storage requirements are much less. The Conduit follower node runs with non-archival storage requirements compared to the archival storage requirements needed by Indexer 2.x. For mainnet at round 32 million, this can save between 1.2TB and 1.6TB of storage.
+
+The postgres requirements are the same, unless the new transaction pruning and filtering features in Conduit are used. For some applications, this can save another 1.5 TB or more of storage.
+
+## Are debian and rpm packages supported for Conduit and Indexer 3.x?
+
+No, these are not currently supported.
+
+## How long does it take to synchronize a new deployment?
+
+With an optimal deployment, the process can take less than a week, but it is common for the process to take 3+ weeks. The process is typically disk and network bound.
+
+For optimal performance ensure:
+	* A fast network connection.
+	* Low latency between Conduit, the follower node and postgres.
+	* Fast disk, locally attached NVMe is ideal for Conduit and algod.