Hey all, in addition to what @Drrickryp so awesomely posted, I thought I could chime in with the thought that considering how much data you need is pretty important.
Can you write a filter that will pull in enough data to do what you need or do you need all that data? If you are developing a purely online solution, you may be able to pull in a filtered set that does the trick. If you are developing an offline solution or in certain situations, you may need more. There are ways to get around the limit but there are costs to consider, like storage and loading times, as well as general complexity issues you may encounter later on.
I have a method that I use to pull in 10,000 rows of maintenance data to a phone-based app. The reason for this is that the app is designed for offline use and needs to be pretty much self-contained. Plus, some of the maintenance tasks are annual, so ensuring that enough data is on-hand to keep the last maintenance record isn't guaranteed in 2000 records. Offline development is a tenuous task in PowerApps as I don't think it was really meant for this kind of use and it's real-world ability to do so isn't exactly solid yet. 
That said, here is some code to show how it can be done as well as illustrate the complexity involved. This is production code from an app that has been in use for over a year. I am in the process of overhauling the app due to some changes in our maintenance program, but this bit will be reused. Also, this idea was not mine; I borrowed and adapted it from someone else, though sadly I don't remember who or where from. (If you read this and it was you, please comment so I can thank you!)
// I refresh the data source to ensure I am getting the most recent data
Refresh('[dbo].[MaintenanceRecord]');
// Then I start a clean collection, sorting by ID in my case
ClearCollect(MaintenanceRecordCollection, Sort('[dbo].[MaintenanceRecord]', ID, Descending));
// This variable tracks the ID where the collection ended so it knows where to start the
// next time around.
UpdateContext({MinID: Min(MaintenanceRecordCollection, ID)});
// I then check if the first collection is at a full 2000 records. If so, I filter out everything above
// that last ID and collect another round of data to the collection. If the first collection has
// less than 2000 records, there wasn't anything more to collect and the If statement ends. I then update the
// variable that stores the minimum ID that I have collected.
If(CountRows(MaintenanceRecordCollection)=2000,
Collect(MaintenanceRecordCollection,
Filter(
Sort('[dbo].[MaintenanceRecord]',
ID,
Descending
),
ID < MinID
)
)
);
UpdateContext({MinID: Min(MaintenanceRecordCollection, ID)});
// I do the same as before, this time checking to see if there are 4000 items. If not, it is
// done. If so, it repeats the process to collect up to 2000 more items. It again collects
// the minimum ID.
If(CountRows(MaintenanceRecordCollection)=4000,
Collect(MaintenanceRecordCollection,
Filter(
Sort('[dbo].[MaintenanceRecord]',
ID,
Descending
),
ID < MinID
)
)
);
UpdateContext({MinID: Min(MaintenanceRecordCollection, ID)});
// Lather, rinse, repeat, adding 2000 items each time.
If(CountRows(MaintenanceRecordCollection)=6000,
Collect(MaintenanceRecordCollection,
Filter(
Sort('[dbo].[MaintenanceRecord]',
ID,
Descending
),
ID < MinID
)
)
);
UpdateContext({MinID: Min(MaintenanceRecordCollection, ID)});
// Pretty exciting stuff, right? Lots of repeating essentially the same thing, just changing the measuring point.
If(CountRows(MaintenanceRecordCollection)=8000,
Collect(MaintenanceRecordCollection,
Filter(
Sort('[dbo].[MaintenanceRecord]',
ID,
Descending
),
ID < MinID
)
)
);
// Lastly, I save the collection locally.
SaveData(MaintenanceRecordCollection, "LocalMaintenanceRecord");
Now, in my case I use the ID but there may be a better field to use. At the very least, this is a proof of concept and could spurn some ideas for what your solution may look like. Also, while this is possible, it may not be beneficial for your use case. Considering your needs and the hardware your users will be using is important, as well as how much complexity is manageable for you and, if you are lucky enough to have one, your team. If you don't have a team (I fall into this category) you could stand to think through the implications this may have on your successor and the organization at large. Documentation is a difficult aspect in PowerApps and while you can comment the code now, knowing where to look to find the right comments can be a challenge.
PowerApps is a great tool and capable of many creative solutions. And again as @Drrickryp stated, there are many people on these forums who are willing to help others solve issues they encounter. Best of luck to you in your endeavors!
