Postgres and GIS at Nextdoor: Engineering for Scale

Do you have a Django app built on Postgres that needs to use geospatial data? Want to know how to scale it to millions of users using Postgres?  In this article, I interview Ananth Chandrasekharan about the challenges Nextdoor faced while scaling its Django application, which made heavy use of geospatial data, and how they successfully overcame these challenges. Ananth is seasoned engineering leader with decades of experience working at top tech companies such as Coinbase, Nextdoor and Rippling.

Nextdoor is a localized social networking platform that utilizes geospatial data to connect users with their actual neighbors and surrounding community. Geospatial data forms the basis of the neighborhood definition as well as the user verification process. Various applications at Nextdoor make regular use of this data by executing a large number of geospatial queries. Geospatial queries can be computationally intensive and may produce large result sets of geometry data adding to the load on the database.

As Nextdoor grew, the single Postgres database and monolithic architecture of their Django app became a performance bottleneck, and resulted in outages under load. To enhance scalability and reliability, they split the monolithic database in two. A dedicated geospatial service, supported by a separate Postgres database named Atlas, was developed.

Check out the video for the complete interview, but here are some of the highlights:

Background and Context:

• Ananth detailed his experience at Nextdoor, where he faced scalability issues with their Django-based application using Postgres, particularly around geospatial data handling.

Challenges Faced:

• Geospatial queries caused performance issues and outages, necessitating the migration of geospatial data to a separate database & service.
• Mismatch between Django ORM and the database structure, leading to inefficient queries and performance bottlenecks.
• Significant amount of geospatial data, constituting half of the database, led to large backups and scalability issues.

Migration Strategy:

• Gradual migration to a new system, introducing a separate geospatial service to reduce load on the main database.
• Initial dual writing to both the old and new databases to ensure stability and data integrity during the transition.
• The migration involved rigorous testing, including API performance testing, and was conducted slowly to avoid disruptions (started with 1% of traffic and scaled up).

Technical Solutions Implemented:

• Use of PostGIS for geospatial indexing.
• Schema changes to allow more flexibility and scalability, such as private and public tables for different countries to facilitate international expansion without downtime.

Outcome and Benefits:

• Elimination of outages caused by poorly running queries.
• Enabled international expansion due to improved database management and schema flexibility.
• Switch from Django ORM to SQL Alchemy in the new service improved the quality of SQL queries.

Lessons Learned:

• Importance of proper planning and pacing of infrastructure projects.
• Necessity of clear communication about the benefits and timeline of major technical projects to gain company-wide support.

Conclusion:

Splitting the Django monolith & migrating to a dedicated geospatial data service not only resolved performance issues but also positioned Nextdoor for future growth, particularly in handling international data seamlessly.

If you enjoyed this interview and want to learn more, you can read this post by Bhuvan Bamba from the Nextdoor engineering blog.