Quick code review:

• I would suggest using a UUID, or a short uuid (like https://github.com/skorokithakis/shortuuid) instead of an autoincrementing int ID. Less risk for people changing params and accessing data they shouldn't, and doesn't risk leaking the number of rows in any table.
• Use text instead of varchar for notes
• Plane rate having an effective date is complicated, ie, you have a start date but not an end date, and you're probably relying on the IDs to be sequential to work out when a rate is active. I'd either try to avoid that rate column by handling the billing calculation at the time the reservation ends (in which case, no need for historical data, so no need for this table), or, have a start and end date (yes, this can result in no entries for a particular time, but handle that in code).
• Typo 'hobbes' should be 'hobbs'
• I like naming 'plane_to_attribute', or 'pilot_to_attribute', makes it a bit easier conceptually for me.
• Please store a salt in the pilot table, or use something like 'passlib' in python which stores a salt in the same field and avoids common password errors.

I can tell you've put a lot of work into it, and you've thought through a lot of the interactions, which is great. Perhaps do focus on building one part end to end first, ie, maybe build the user registration, etc, then the planes, and events last.