We are roughly six weeks into the 2026 MLB season, and the “small sample size” warnings are finally starting to wear off. While the league is buzzing about José Soriano’s absurd 0.28 ERA in Anaheim or the rookie dominance of Parker Messick in Cleveland, I wanted a way to cut through the noise on my own terms.
The idea was simple: I wanted a high-speed way to see which starting pitchers are actually commanding the zone and which are just getting lucky. Instead of clicking through endless cloud-based dashboards, I built a local ingestion engine that grabs Statcast data and runs the numbers on my own hardware.
What the Scout Sees Today (May 12, 2026)
Running the numbers this morning, a few things jump out that the standard box scores might be missing:
The Workhorse Efficiency: While everyone is watching the strikeout leaders like Jacob Misiorowski (who is currently punching out 14+ per nine innings), the system is highlighting Max Fried. He’s leading the league in innings pitched (33.1) with a WHIP of 0.81. That’s “Sovereign” command—efficient, repeatable, and dangerous.
The Command Extremes: My app isn’t just looking for the “best”—it’s looking for the “outliers.” Right now, it’s flagging Shota Imanaga for having the lowest WHIP in the league (0.72) despite not having the highest velocity. It’s a masterclass in movement over muscle.
The Red Flags: On the flip side, we’re seeing a few veteran arms where the “late-inning fade” is starting to show up in the data earlier than usual.
Why Build Your Own?
You might ask why I didn’t just check a fantasy site. For me, it’s about Data Agency. By building my own interface, I can weight the metrics I care about—like spin-to-velocity correlation—without having to wait for a third party to update their rankings.
This is just a quick run of the data for now. I’ll likely check back in later this summer to see how these early-season trends hold up once the “dog days” of July hit.
Stay tuned—and if you’re a data geek, feel free to poke around the repo. Alternatively, if you want a glimpse at the interface (rate limits apply) take a look at the website.
Having data stored in a database is practically a given for today’s businesses. Customer information, order history, product pricing, IoT sensor data, and much more is being recorded for future use. However, just having the data stored isn’t enough to form a competitive market advantage. We must be able to analyze the data as well. There are many options to do so and in a variety of ways. If you have data that needs to be visually analyzed in MongoDB, MongoDB Charts is a terrific option.
Prior to MongoDB Charts, there were really three ways to visualize your MongoDB Data.
Perform Extract-Transform-Load (ETL) operations and leverage third-party tools, or
Write custom code and use charting libraries such as D3.js or Bokeh.
MongoDB Charts Benefits
MongoDB Charts, currently in Beta, provides an easy way to visualize your data living in MongoDB. You don’t need to move your data to a different repository, write your own code, or purchase third-party tools. MongoDB Charts knows and understands the richness of the Document Data Model and allows for easy data visualization.
Further, MongoDB Charts allows for a secure way to create and share visualization dashboards with everyone, or just targeted team members. Similarly, the data source being used behind the scenes can be shared securely as well. For example, data for the Sales Department doesn’t have to be made available to Marketing unless needed. Very powerful and follows MongoDB’s design of security being a top priority.
After downloading the MongoDB Charts Docker image and following the installation instructions, we’re able to connect to a data source stored in MongoDB Atlas and start making visualization dashboards. Once connected to the MongoDB Charts server, there are three steps we need to take:
Add a data source
Create a dashboard
Create our charts
Analyzing Airbnb Data with MongoDB Charts
I have set up a database with some Airbnb data from various cities. We’ll be exploring the dataset from Seattle, WA here, but feel free to explore others on your own. We need to get the connection string from the Atlas Cluster that has our data and connect to it in Charts.
Get URI from MongoDB Atlas
Add a Data Source
With our MongoDB Charts server running on localhost:80, we can log in and head to the Data Sources tab. We use the URI from Atlas (mongodb+srv://airbnbdemo:airbnb@airbnb-rgl39.mongodb.net/test?retryWrites=true) and select Connect. We’re next asked which data source we want to use from that cluster, I’ll select the seattleListingAndReviews from the airbnb database for this example. For permissions, I just want to keep everything private so I’ll accept the defaults and select Publish Data Source. Once published I can add an alias to the data source. I’ll call it Airbnb Seattle.
Note: The URI above contains a sample URI. You should connect to your own Atlas Cluster and use an authorized username and password.
Create a Dashboard
Next up is to create an actual dashboard to house our visualizations. In the Dashboards section choose New Dashboard and give it a name and description, like Ken’s Airbnb Dashboard. This will take me to where I can add charts to my dashboard.
Create a Chart
After clicking on the Add Chart button we can start building our visualization. We’ll want to choose the Airbnb Seattle data source from the drop-down. MongoDB Charts automatically determines which fields are available for exploration. For this exercise, I’d like to see which neighborhoods in Seattle have the most Airbnb properties and split them by property type. We’ll use the Stacked Bar chart for the type.
For the X-Axis then, we’ll want the id field, aggregated by count.
Assign X-Axis value to a MongoDB Chart
Along the Y-Axis we’ll look at the address and the suburb. Notice that address is a subdocument here and that MongoDB Charts natively knows how to handle this type of data. I’d like to sort the suburb by aggregated value, in descending order, and limit our results to the top 20 suburbs.
Assign Y-Axis value to a Stacked Bar chart
Let’s add the property_type field as our series
Assign a Series value to a Stacked Bar chart
Now we can name our chart, Properties by Location and save it. We’re then taken back to our dashboard where we can add other visualizations for further exploration.
Have a look at this short video to see some other visualizations being created from this same data source.
Conclusion
MongoDB Charts is an excellent new tool to visually explore your data. It has some great features for specific use cases, such as:
Ad hoc analysis of your data
Natively understands the benefits of the Document Data Model
Collaboration on projects is easy with user-based sharing and permissions
It’s intuitive enough for non-developers to use allowing for self-service data analysis
MongoDB Charts is the fastest way to build visualizations over your MongoDB data. I’d encourage you to download it and try it out today. Let me know what visualizations you come up with from the Airbnb dataset. I always enjoy seeing how people explore their data.
This post was first published on the MongoDB blog.
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_ga_
ID used to identify users
2 years
_gid
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
X Pixel enables businesses to track user interactions and optimize ad performance on the X platform effectively.
This cookie is set by X to identify and track the website visitor. Registers if a users is signed in the X platform and collects information about ad preferences.
2 years
personalization_id
Unique value with which users can be identified by X. Collected information is used to be personalize X services, including X trends, stories, ads and suggestions.
2 years
external_referer
Our Website uses X buttons to allow our visitors to follow our promotional X feeds, and sometimes embed feeds on our Website.