A complete ride-sharing database schema designed for on-demand transportation platforms. Includes rider and driver profiles, ride requests with pickup/dropoff locations and fare calculation, payment processing, and mutual rating systems. Suitable for building apps like Uber, Lyft, or custom ride-hailing solutions.
rides stores four coordinates and two addresses for one trip. The addresses are what people read and the latitude and longitude pairs are what the system computes with — distance, routing, matching — and keeping both means a receipt stays readable while the geometry stays usable.
ratings carries a from_rider boolean rather than two separate tables. Both parties rate each other after the same trip, so one row with a direction flag covers it — and the aggregate rating columns on riders and drivers are the cached result of those rows.
driver_id is nullable on the ride, which is the whole dispatch model in one column. A ride exists from the moment it is requested, before anyone has accepted it, and assignment is an update rather than a row in a queue.
Recalculating from distance and a current rate would restate every historical trip the day pricing changes, and would ignore surge, tolls and promotions that applied at the time. Freezing fare on the ride is what makes a receipt true. distance_km is kept beside it for the same reason — as evidence of how the number was reached, not as an input to recompute it.
Two tables would duplicate every column to express the same event seen from opposite ends. A from_rider flag keeps one row shape and makes a trip's feedback a single read. The cost is that constraints are weaker — nothing but application logic stops two ratings in the same direction for one ride.
is_available on the driver makes finding someone to dispatch a single indexed read. What it cannot express is why they are unavailable, how long they have been waiting, or where they are — real dispatch needs a continuously updated location with a spatial index, which this schema deliberately leaves out.
Separate lat and lng columns are portable and readable anywhere, and they cannot use a spatial index. For storing where a trip began and ended that is fine; for finding the nearest driver it is not, which is why a production system adds a geography type or a geohash while keeping these columns as the trip record.