The Exceptions That Break the Rule: Using the Outlier Pattern in MongoDB

Some times there's a schema design that's perfect for 99% of your entities, but there's that odd instance that just doesn't fit. This article explains how to use the outlier pattern to handle those exceptions while optimising for the majority.

When Should You Use a Cache With MongoDB?

To answer the question in the title of this article — when should you use a cache with MongoDB? — the answer is probably never. This article attempts to explain why, but if you get to the end and still think your application needs it, then I’d love to discuss your app with you.

Process vs Payload Fields — Efficiently Querying Semi-structured MongoDB Documents

In a recent MongoDB design review, I was presented with a use case where the customer wanted to store a large amount of semi-structured message data in MongoDB. They also needed to efficiently fetch past messages based on specific query criteria.

One of the key concepts I applied when making my recommendations was to distinguish between “process” and “payload” fields. Process fields are those that your queries filter on. Payload fields contain the data that needs to be stored and retrieved but aren’t part of any query filter.

In this post, I describe their use case, my schema and index recommendations, and the process of getting from the requirements to the solution. I’ve changed some use case details to protect the customer’s proprietary information, but the recommendations are real.

Using MongoDB Schema Validation With the Schema Versioning Pattern

One of MongoDB’s most appreciated features is that it’s very easy to change your schema as your application evolves. For example, unlike with an RDBMS, you don’t need to make every record conform to the modified schema by adding null values when you add a new field. Note that it’s best practice to just leave out fields in MongoDB documents rather than storing null values — it saves storage, and makes documents easier to understand.

However, when your application reads a document from the database, it simplifies things if it can tell what it’s seeing. Including an application-defined field denoting a schema version number in each document lets the application know what to expect. Including a schema version can also be useful when you’ve had to restore a backup that contains older schema versions.

This article explains how to enjoy the freedom of MongoDB's flexible data model, while ensuring that your documents contain what you expect.

Understand What Happens in a MongoDB Design Review

Recording of a design review where my colleague (Luce) and I step through what actually happens in a review.

Luce plays the role of a developer responsible for migrating a property booking services from a relational database to MongoDB.

By the end of the review we have a high-level schema design that will power the application.

From RDBMS to NoSQL at Enterprise Scale

Presentation at MongoDB .local London 2024.

I explain why denormalization and the RDBMS was created in the 1970s and dominated for the following decades.

Then I explain why that model didn't age well and why in today's world it can't deliver the performance and efficiency that modern applications need.

I show how MongoDB's document model gives you the flexibility to implement a schema that's optimized for your most critical operations.

Pop Quiz: Optimizing Data Designs for High Performance

Presentation at MongoDB .local London 2024.

This ia a chance to test your knowledge on the performance impacts from the decisions you make while designing your MongoDB schema and indexes.

Real Benefits of Teaming up with MongoDB to Review a Data Model

Presentation at MongoDB .local NYC 2024.

Together with Antoine Speller, I explain the benefits of booking a 1-hout design review with the MongoDB Developer Advocacy. They're free of charge and can make a huge difference to the performance and maintainabilty of your application.