Moving to MongoDB with Michael Kennedy

Summary

There are dozens of decisions that need to be made when building an application. Sometimes this can lead to analysis paralysis and prevent you from making progress, so don’t let the perfect be the enemy of the good. This week Michael Kennedy shares his experience with evolving his application architecture when his business needs outgrew his initial designs.

Preface

• Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
• I would like to thank everyone who supports us on Patreon. Your contributions help to make the show sustainable.
• When you’re ready to launch your next project you’ll need somewhere to deploy it. Check out Linode at www.podastinit.com/linode?utm_source=rss&utm_medium=rss and get a $20 credit to try out their fast and reliable Linux virtual servers for running your awesome app.
• Visit the site to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch.
• To help other people find the show please leave a review on iTunes, or Google Play Music, tell your friends and co-workers, and share it on social media.
• Your host as usual is Tobias Macey and today I’m interviewing Mike Kennedy about his work scaling his apps and his business

Interview

• Introductions
• How did you get introduced to Python?
• In some of your recent episodes you have mentioned the work that you did to migrate your applications to run on MongoDB. Can you start by describing the business case for these applications and how you arrived at the initial design?
• What was the limiting factor that led you to consider such a drastic shift in how you store and manage your data and what benefits did you gain when the work was complete?
  • If the issue was with scaling, how did you identify the choke points?
  • Why go from relational (SQLite) to document (Mongo) instead of what would seem a more obvious choice of a production grade relational engine such as PostGreSQL or MySQL?



• Are there any particular synergies that arise from using a document as opposed to a relational store when working with Python and what are some of the main considerations when deciding between them?


• What was happening in your business that precipitated the need for this work?


• How are you talking to MongoDB from Python? Directly (via pymongo) or ORM-style?
  • Why did you make that choice?
  • How well is that working out? Advantages / drawbacks?



• In addition to podcasting you have also been working to create a number of successful courses to teach people how to use Python. Is there anything specific to the language that translates into how you design the material?


• For anyone who wants to learn more about the benefits and tradeoffs of using a document store with their Python applications, what are some resources that you recommend?

Keep In Touch

• Michael
  • @mkennedy on Twitter
  • Websites
    • Talk Python
    • Python Bytes

  
  
  
  

Picks

• Tobias
  • Org Mode
  • Levar Burton Reads



• Mike
  • Newspaper
  • Robomongo (now Robo 3T)
  • The Dark Secret at the Heart of AI
  • Haibike SDURO Cross 4.0

Links

• SQLAlchemy
• SQLIte
• MySQL
• PostGreSQL
• NoSQL
• MongoDB
• Database Normalization
• Foreign Keys
• Document Database
• Rollbar
• MongoEngine
• Mongo Security Checkup
• MLab
• MongoDB Atlas
• MongoDB World
• O’Reilly Python Mongo Book
• MongoDB For Python Developers
• Momentum Dash

The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA