Month: July 2025

Posted on mongodb google news. Visit mongodb google news

M&T Bank Corp reduced its holdings in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 17.1% during the first quarter, according to its most recent disclosure with the Securities and Exchange Commission (SEC). The fund owned 2,518 shares of the company’s stock after selling 519 shares during the period. M&T Bank Corp’s holdings in MongoDB were worth $442,000 at the end of the most recent reporting period.

A number of other institutional investors and hedge funds have also bought and sold shares of MDB. OneDigital Investment Advisors LLC grew its holdings in shares of MongoDB by 3.9% in the fourth quarter. OneDigital Investment Advisors LLC now owns 1,044 shares of the company’s stock worth $243,000 after purchasing an additional 39 shares during the last quarter. Handelsbanken Fonder AB grew its holdings in shares of MongoDB by 0.4% in the first quarter. Handelsbanken Fonder AB now owns 14,816 shares of the company’s stock worth $2,599,000 after purchasing an additional 65 shares during the last quarter. O Shaughnessy Asset Management LLC grew its holdings in shares of MongoDB by 4.8% in the fourth quarter. O Shaughnessy Asset Management LLC now owns 1,647 shares of the company’s stock worth $383,000 after purchasing an additional 75 shares during the last quarter. Fifth Third Bancorp grew its holdings in shares of MongoDB by 15.9% in the first quarter. Fifth Third Bancorp now owns 569 shares of the company’s stock worth $100,000 after purchasing an additional 78 shares during the last quarter. Finally, Moody National Bank Trust Division grew its holdings in shares of MongoDB by 5.6% in the first quarter. Moody National Bank Trust Division now owns 1,751 shares of the company’s stock worth $307,000 after purchasing an additional 93 shares during the last quarter. 89.29% of the stock is currently owned by institutional investors.

Insider Transactions at MongoDB

In other news, Director Hope F. Cochran sold 1,174 shares of MongoDB stock in a transaction dated Tuesday, June 17th. The stock was sold at an average price of $201.08, for a total value of $236,067.92. Following the completion of the transaction, the director owned 21,096 shares of the company’s stock, valued at $4,241,983.68. The trade was a 5.27% decrease in their position. The transaction was disclosed in a document filed with the Securities & Exchange Commission, which is available through the SEC website. Also, Director Dwight A. Merriman sold 2,000 shares of MongoDB stock in a transaction dated Thursday, June 5th. The stock was sold at an average price of $234.00, for a total value of $468,000.00. Following the completion of the transaction, the director directly owned 1,107,006 shares of the company’s stock, valued at approximately $259,039,404. This represents a 0.18% decrease in their position. The disclosure for this sale can be found here. Insiders sold a total of 32,746 shares of company stock valued at $7,500,196 in the last quarter. 3.10% of the stock is owned by insiders.

Analyst Upgrades and Downgrades

MDB has been the topic of several recent analyst reports. Citigroup cut their target price on shares of MongoDB from $430.00 to $330.00 and set a “buy” rating on the stock in a report on Tuesday, April 1st. Loop Capital cut shares of MongoDB from a “buy” rating to a “hold” rating and cut their target price for the stock from $350.00 to $190.00 in a report on Tuesday, May 20th. Morgan Stanley cut their target price on shares of MongoDB from $315.00 to $235.00 and set an “overweight” rating on the stock in a report on Wednesday, April 16th. Macquarie restated a “neutral” rating and issued a $230.00 target price (up previously from $215.00) on shares of MongoDB in a report on Friday, June 6th. Finally, DA Davidson restated a “buy” rating and issued a $275.00 target price on shares of MongoDB in a report on Thursday, June 5th. Eight analysts have rated the stock with a hold rating, twenty-six have assigned a buy rating and one has given a strong buy rating to the stock. According to data from MarketBeat, the company presently has a consensus rating of “Moderate Buy” and a consensus price target of $282.39.

Check Out Our Latest Report on MongoDB

MongoDB Trading Up 0.5%

Shares of MongoDB stock opened at $209.64 on Thursday. The firm has a market capitalization of $17.13 billion, a P/E ratio of -183.89 and a beta of 1.41. The business has a fifty day simple moving average of $201.07 and a two-hundred day simple moving average of $213.37. MongoDB, Inc. has a 12 month low of $140.78 and a 12 month high of $370.00.

MongoDB (NASDAQ:MDB – Get Free Report) last announced its quarterly earnings data on Wednesday, June 4th. The company reported $1.00 EPS for the quarter, beating the consensus estimate of $0.65 by $0.35. The business had revenue of $549.01 million during the quarter, compared to analyst estimates of $527.49 million. MongoDB had a negative return on equity of 3.16% and a negative net margin of 4.09%. The company’s revenue for the quarter was up 21.8% on a year-over-year basis. During the same quarter last year, the firm posted $0.51 earnings per share. Analysts predict that MongoDB, Inc. will post -1.78 earnings per share for the current year.

About MongoDB

(Free Report)

MongoDB, Inc, together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

Featured Stories

Want to see what other hedge funds are holding MDB? Visit HoldingsChannel.com to get the latest 13F filings and insider trades for MongoDB, Inc. (NASDAQ:MDB – Free Report).

Receive News & Ratings for MongoDB Daily – Enter your email address below to receive a concise daily summary of the latest news and analysts’ ratings for MongoDB and related companies with MarketBeat.com’s FREE daily email newsletter.

Article originally posted on mongodb google news. Visit mongodb google news

Article originally posted on InfoQ. Visit InfoQ

Transcript

Oda: I wonder if any of you could guess what this number, 1 out of 4, may represent? You might be surprised to hear that actually this number represents today’s 20-year-old becoming disabled before they retire. This could be caused by accidents, disease, or their lifestyle, or it could be anything that happens that’s disastrous in their lifetime. It’s been estimated that about 1.3 billion people worldwide have significant disability today, which is roughly 16% of the world population.

As humans live longer, the chance of having a disability increases. Starting in the mid-1800s, human longevity has increased a lot, and the life expectancy is increasing by an average of six hours a day. The point is that we all hope to live healthy and without any disabilities, but that’s not always the case. Anyone can have a certain type of disability during their lifetime. There are actually many types of disabilities that exist, and I know these are not legible and that’s on purpose. For my topic, I’ll be specifically focusing on visual impairment-related disabilities, such as blindness and low vision.

My name is Ohan Oda. I work on Google Maps as a software engineer. I’ll be talking about how we made our augmented reality feature, called Lens in Maps, accessible to visually impaired users, and how our learnings could apply to your situation. I wonder how many of you here have used the feature called Lens in Maps in Google Maps? Just a hint, it’s not a lens. It’s not street view. It’s not immersive view. It’s not one of the AR Walking Navigation that we provide that has a big arrow overlaid in the street. It’s a different feature. Most of you don’t know.

What is Lens in Maps?

First, let me introduce what Lens in Maps is. It’s a camera-based experience in Google Maps that helps on-the-go users understand their surroundings and make decisions confidently by showing information in first-person perspective. Here’s a GIF that shows how Lens in Maps works in Google Maps. The user enters the experience by tapping on the camera icon at the top on the search bar, and the user will hold their phone up, and they can see places around them. They can also do search for specific types of places, such as restaurants. Here’s a video showing how this feature works with screen reader, which is an assistive technology often used by visually impaired users.

Allen: First, we released new screen reader capabilities that pair with Lens in Maps. Lens in Maps uses AI and augmented reality to help people discover new places and orient themselves in an unfamiliar neighborhood. If your Screen Reader is enabled, you can tap the camera icon in the search bar, lift your phone, and you’ll receive auditory feedback about the places around you – Restaurant Canet, fine dining, 190 feet – like ATMs, restaurants, or transit stations. That includes helpful information like the name and type of the place you’re seeing, and how far away it is.

Oda: Here you saw an illustration of how this feature works with screen reader.

Motivation

AR is a visual-centric experience. Why did we try to make our AR experience accessible to visually impaired users? Of course, there are apps like Be My Eyes that is targeted specifically for visually impaired users. Our feature, Lens in Maps, was not designed for such a case. Indeed, there are not many AR applications that exist today that are usable by visually impaired users. Lens in Maps is useful when used during traveling, where the place or the language is not familiar to the user. Our feature can show the places and streets around the user with the language that the user is familiar with.

However, this feature is not used very often in everyday situations, because people know the places and they understand the language seen on the street. There’s also a friction to this feature. Like any other AR apps that you probably have used before, you have to take out the phone, and you have to hold your phone up and face the direction where the AR elements can be overlaid. This can be sometimes awkward, especially in the public area where people are standing in front of you. They might be thinking you’re actually taking a video of them. In addition to this general AR friction, our feature also requires a certain level of location and heading accuracy relative to the ARs so that we can correctly overlay the information in the real world.

This process is very important so that we don’t mistakenly, for example, overlay the name of the restaurant in front of you with the name of the restaurant next to it. This localization process really only takes a few seconds, but people are sometimes impatient to even wait for just a few seconds, and they would exit the experience before we can show them any useful information. These restrictions make our Lens in Maps feature used less often than we would like it to be. We have spent a lot of time designing and developing this feature, so we would love to have more users using it and also loved by the user.

Ideation

While thinking about ideas, how we can achieve that, I found that our other AR feature that we provide in Google Maps, called AR Walking Navigation, has a very good DAU and has a very good user retention rate as well. This is a feature that is targeted to navigate users from point A to point B with instructions overlaid in the real world with big arrows, big red destination pins as you can see from the slides. Why so? This feature has the exact same friction as Lens in Maps, where people have to hold their phone up and they have to wait for a few seconds before they can start the experience.

After digging through our past documents, our past presentations in our team, I found that our past UX studies have shown that AR Walking Navigation can really help certain users and those users who actually have difficulties reading maps and understanding it. Basically, the directions displayed on the 2D map didn’t make much sense to those users, and showing those directions directly overlaid in the real world really helped them understand which directions to take and where exactly the destination is, which made me think what kind of user would really benefit from using Lens in Maps that eventually it becomes a must-have feature for them. Even though this feature has some restrictions to start the experience, the benefit of using this would actually outweigh the friction.

Research

After thinking over and over, an idea struck me that maybe Lens in Maps could help visually impaired users because our feature can basically show the places and streets in front of them. Not show, but tell, for this case. I thought it was a good idea, but I had to do some research to make sure this feature can really help those users. Luckily, Google provides many learning opportunities throughout the year and they had a few sessions about ADI, which stands for Accessibility and Disability Inclusion. After attending those sessions, I learned that last-mile problems can be very challenging for visually impaired users. The navigation app that you have today may actually tell you exactly how to get to the destination, but once you are at the destination, it’s really up to you or the user to figure out where exactly that destination is.

The app may say the destination is on your left side or right side, but often you realize that the destination actually can be many feet away from you, and it could be in any direction on your left or right side. Also, blind and low-vision users tend to visit places that they have been before and are familiar with, because it’s a lot harder for them to explore new places, because it’s hard to know what places are there, first of all, and it’s hard to get more information about those new places without a lot of pre-planning. Once I learned that Lens in Maps could really help those users, I started to build a prototype and demoed it to my colleagues and also other internal users who have visual impairment.

Challenge

However, as I built my prototype, I realized that there are many challenges, because we are basically trying to do the reverse of the famous saying, a picture is worth a thousand words. It’s actually even worse here because we are trying to describe a live video, which may actually require 1 million words. Also, I myself am not an accessibility expert. Indeed, I was more on the side of avoiding any type of accessibility-related features because it’s really hard to make it work right. I know there are many great tools that exist that can help you debug and create those accessibility features, but a lot of us engineers are probably not that familiar with those kinds of tools, so it takes a lot longer to make those features work right compared to non-accessibility related features.

For first-party apps at Google, there is an accessibility guideline called GAR, which stands for Google Accessibility Rating. These guidelines were not very applicable for a lot of the AR cases we encountered during their development. For example, one of the guidelines recommends that we should describe what’s being displayed on the screen. Unlike 2D UIs, where the user has more control over which element to focus on, what to be described, the objects in the AR scene could move around a lot. The object could even disappear and appear based on how your camera moves, which makes it really hard for the user to decide which things to focus on.

Also, we are detecting places in the world that have a lot of information to present, like the name of the place, the rating of the place, how many reviews it has, what type of place it is, what time it opens, and so on. If the user wants to hear all this information, they have to hold up their phone in a very specific position until all these information is described to them. There are also many other cases that I won’t go through, but these general guidelines that existed before were mostly designed for non-AR cases. The general guidelines basically didn’t apply much for what we have been doing.

Once I have the prototype ready, it was hard for me to tell whether this works or not, because I myself am not a target user. Even though I think it works well, it may not work well for the actual target user. None of my colleagues near me were actually a target user either. It wasn’t very easy for me to test. I basically have to go out and find somebody else from our team that has visual impairment to test it. Last but not least, I’m sure my company doesn’t want to hear about this, but it’s a reality that it’s really hard to get leadership buy-in for this type of project, because often leadership themselves are not the target user. It’s really hard for them to see the real value of this type of feature. These days also companies are under-resourced, and so this type of project tends to get lower priority over others. We indeed had several proposals in the past to make our AR features accessible to visually impaired users, but they always got deprioritized over other more important projects, and they just never got implemented.

Coping with Challenges

How did I cope with all these challenges? As I said, I’m not an expert in this accessibility field. The first thing I did was to reach out to teams who work on technology for visually impaired users, such as the team working on Lookout, which is an Android app that can describe what’s in the image. I explained to those teams how Lens in Maps could revolutionize the way those visually impaired users would interact with maps, and basically demoed my prototype to them. Because they are the specialists in the field, they gave me a lot of good feedback, and I iterated my prototype based on those feedbacks. Now I have my prototype ready to test.

As I said before, I cannot test it myself, so I basically try to find volunteers internally to first check if it’s working ok. Luckily, there are several visually impaired users within Google who are very passionate about pushing the boundary of assistive technology and willing to be early adopters. It’s actually usually hard to find those users within anyone’s company because they are very limited, and they are usually overwhelmed with a lot of requests to test any accessibility features that are being developed in that company. I got a lot of good feedback from those users, and I was able to incorporate again to my prototype and improve it further.

Once the prototype is polished enough or to a satisfying level from the internal testing, I also wanted to test with external users to get a wider range of opinions. I had great support from our internal UXR group who are specialized in accessibility testing. They basically organized, from recruiting to running the tests and everything, with external blind and low-vision users. The study went really well, and actually the response was very positive. From those responses, I was more confident that this feature is getting ready to go public. The study went well, but from those external testing, I actually didn’t get to interact directly with those users. I also wanted to demo my prototype and get direct feedback from external target users. I was looking for where I can do that. Luckily, I was able to find this great conference called XR Access, which is directed by Dylan.

In the conference, I proactively approached two target users and asked if they could try out my prototype. That went well, and I again got a lot of good feedback from the real users, and I was able to incorporate those. Last but not least, when I was developing this feature, it takes several months, so I need to make sure that my project doesn’t suddenly come to an end because of leadership saying, priority has changed, so let’s work on something else. What I did was I tried to demo my prototype to various internal accessibility events to get this project more attention and also get people excited. I don’t know if my effort has really worked out, but at least I was able to release my feature to the public on both Android and iOS.

What Worked Well?

What worked well for us? It worked well that we used technology that blind and low-vision users are already familiar with. We decided to use screen reader technology to describe places and streets around the user. Basically, on iOS, this will be VoiceOver, and on Android, this will be TalkBack. We also considered using text-to-speech libraries, but it won’t be very easy to adjust a lot of the settings, like volume, the speech rate, and those, which blind and low-vision users tend to adjust to suit their needs.

The thing is, also, if we would require them to have additional configuration, that means they have to take extra steps just for Lens in Maps to make those configurations. It made a lot of sense for us to use the screen reader technology. There could be multiple places and streets visible from where the user stands. Like you see here, there are many things there. We can only describe them one at a time because our brain does not process multiple channels of audio very well. You may hear the sound, but it’s hard to understand all of them at once. Not only places and streets, but we also detect situations, like the user might be near an intersection, so we need to tell them that they need to be careful. Or maybe they’re facing a direction that has nothing to see, but if they turn left or right, they could actually see more. In those cases, we also want to notify the user. We iterated multiple times and carefully prioritized what to announce at what situation.

When we describe places and streets, Lens in Maps already had this thing called hover state, which is basically detecting what’s around the center of the image and highlighting those places or streets, as you can see on this slide. We basically made the feature to announce what’s being hovered in our experience. We initially described many things that appear on the screen that is hovered, because that’s what we show in our experience, like here, which has a label that has all the information of the hovered place, and that’s also what the accessibility guideline recommends.

This prevented the user from quickly browsing through different places because they have to wait for a longer time to get all those information, especially in a busy area like downtown. We got great feedback from the Lookout team that we might be over-describing, and it’s probably better for us to shorten the description, even though it may not exactly match what they see on the screen. We decided to only describe what’s most important to the blind and low-vision users at the moment, which is the name of the place, the type of the place, and distance to the place. For example, as you see in this slide, instead of announcing T.J.Maxx, 4.3 stars, department store, open, closes at 11 p.m., which is what you usually hear if you’re using any other 2D device with screen reader technology. We instead only announced T.J.Maxx, department store, 275 feet.

If we only provide this succinct description, the user won’t know if it’s really a place they want to visit. We provide an easy way for the user to get detailed information when they want to see, like the one seen on the right side of this slide. We added double-tap interaction on the screen to bring up this information. This interaction may not be obvious to the user, so we added a hint of the succinct description so that they can actually get more information by double-tapping. Using the example before, we would announce T.J.Maxx, department store, 275 feet, double-tap for details.

We only made changes to existing Lens in Maps behavior that is absolutely needed, such as disabling an action to go into 2D basemap view, which didn’t help much for the visually impaired users, because they can’t get any information out of the 2D, and it’s hard to know the distance to anything. We also hide places that are just too far away for them to walk to within five minutes. We made small adjustments here and there, but we tried to minimize those changes. This is important, otherwise it would be really hard to maintain the application in sync between screen reader and non-screen reader experiences. Whenever you modify or add a new feature to your experience, you have to make sure that it doesn’t break the other experience, and if their experience is too different, then there’s more chance of breaking the other one.

If the experience really diverges a lot, then, at that point, there’s no point of having a single application to support it, and at that point, it’s better to just create another one. Besides auditory feedback, haptic feedback can also help blind and low-vision users, and it won’t interfere with audio cues when it’s being used right. We use the general vibration to indicate that something is hovered. Before we can describe the place to the user, we have to fetch additional information from our server, and this means the user, when they hover something in the screen, they have to wait for a few seconds before we’re ready to announce anything.

For this wait time, if we announced loading every time, that would be annoying because we have a lot of things, a lot of places that we detect. Instead of that, we change it to haptic feedback so that the user will, over time, learn that whenever they feel this small haptic feedback, they need to wait a little bit before they can hear the information.

How to Apply Learnings

How can you apply our learnings to your situation? I won’t say that every AR app should work for users with visual impairment because, again, AR is a visual-centric experience. Most of the cases, it works best for sighted users. However, it would be really great for you to at least think whether your AR application could be useful or entertaining to blind and low-vision users, if you make them accessible. As an example, the IKEA app has a very useful AR feature that allows the user to overlay the furniture in their room. The 3D furniture blends really well with the actual environment. The left sofa is a fake one, and the right chair is the real one.

As you can see from here, it uses all the lighting conditions of the room and surroundings. It looks almost like it’s there. For people using this feature today, they use this feature to see if the furniture fits well in their space before they make the decision to buy. However, when I tried this feature on Android with TalkBack turned on, it didn’t describe what’s happening in the AR scene. Of course, it was covering all the 2D UIs, what it says or what it does, but whatever happens in the AR scene, there was no description. Also, I couldn’t do any interaction with the 3D model using the general interaction model provided by TalkBack. I would imagine if this feature could be made accessible, it will really help visually impaired users to explore new furniture before they actually buy them. Once you have determined that your AR app can be useful or entertaining for blind and low-vision users, making sure it’s accessible doesn’t mean you have to change a lot.

Like I said before, it’s important to keep the behaviors in sync between screen reader and non-screen reader experience, so it doesn’t become a burden to maintain or improve in the future. Also, there’s no need to explain everything that’s going on. A picture is worth a thousand words, but the user doesn’t have the time to listen to a thousand words. Try to make it succinct and only extract the most important information the user needs to know at the moment. However, make sure you can also provide a way to get additional information if the user requests, so that they can explore further.

As part of the make it succinct principle, it’s a good idea to combine auditory feedback with haptic feedback, since they can be sensed simultaneously. Try to use haptic feedback like gentle vibration when the meaning of the vibration is easy to figure out after a few tries. You may also change the strength of the vibration to give it a different meaning, but make sure you don’t overuse haptic feedback for many different meanings, because the strength of the vibration is very subtle to sense.

Real User Experience (Lens in Maps)

Now I’d like to show a short video from Ross Minor, who is an accessibility consultant and content creator. He shared how Lens in Maps helped him.

Minor: For the accessibility features that I really liked, I really love the addition of Lens in Maps. It’s honestly just a gamechanger for blind people, I feel, when it comes to mobility. I talked about it in my video. Just GPSs and everything, they’re only so accurate and so just being able to move my phone around and pretty much simulate looking, has already helped me so much. This is a feature I literally use all the time when going out and about. Some use cases that I really have benefited from is when I’m Ubering.

A lot of times I’ll get to the destination, and places can be wedged between two buildings, or buried, or whatever, and it’s difficult to find. In the past, my Uber drivers would always be like, “Is it right here, this is where you’re looking for?” I was like, “I can’t tell you that. I don’t know”. Now I’m able to actually move my phone around and say, yes, it’s over there, and saying it’s over there and pointing is like a luxury I’ve never had before. There have very much been cases where my Uber is about to drop me off at the wrong place and I’m like, no, I see it over there, it’s over that way. It’s a feature I use all the time. I’m just really happy to have it, and it works so well.

Oda: It’s really great and rewarding to hear this type of feedback from a user, that it’s a gamechanger to the user.

Prepare Your Future-Self

Now we’re back to stats again. Roughly 43 million people living with blindness and 295 million people living with moderate to severe visual impairment worldwide. You might be thinking that you are advancing the technology for people with disabilities. That’s great, but, remember, you’re not only helping others, but you might be helping your future self. Let’s prepare for our future self.

Lens in Maps Precision vs. Microsoft Soundscape

Dylan: Obviously, this is fantastic work. I’m really glad that it’s out there and improving people’s lives. I’m very curious to compare these features to something like Microsoft Soundscape, which I think used GPS mostly to figure out, there’s stuff around you in this direction in that direction, and help people explore and get a sense for a space. It feels like here the major advantage that this would have over that is that ability to be much more precise, to use those visual markers, understand, you are specifically looking at this. What are some of the specific things that that level of precision enables that an app like Soundscape may not be able to do?

Oda: As Ross in the video shared, for example, he was riding with his Uber driver. From Soundscape he uses GPS and compass and all those information to tell you, these are places around you. It may even tell you that your destination is 100 meters away from you. The thing is, it doesn’t have the ability to tell you which direction, and that actually sometimes can be very difficult. One of the sessions I learned from our internal ADI session is that they know that they’re near a destination, but the question is, where exactly is that? In the video actually they shared with us their story, is that they reached the destination and they have to wander around 10 minutes to actually find where exactly that destination is. That made me think that if we can provide this exact preciseness based on your phone, which is basically the direction you’re facing, so you know, it’s on that direction. This level of precision really helped for those last-mile cases.

Questions and Answers

Participant 1: Earlier you described that there was friction in holding up the camera. I was wondering if that was consistent around the world or if there are certain countries where Lens in Maps was less used because of that or any other reason.

Oda: I think that’s probably not the first reason that the feature itself is being used less. It is more of the cases people don’t understand they’re supposed to use this outside. Also, there are certain places in the world that we don’t have a lot of information because the technology heavily depends on street view collection. The way we detect where exactly you stand and where exactly you’re facing is based on comparing your image with street view information, which is a technology called VPS. Of course, there is some social awkwardness, especially if people are in front of you and if you’re holding your phone up, they may think you’re taking video.

Actually, we were being intimidated when we were testing this feature outside. Not just for the accessibility feature but just testing these Lens in Maps in general, that even though we’re actually facing the restaurant because people pass by, they sometimes think, we’re taking their video. There’s definitely a certain level of friction from there. The only thing is it’s really hard to know from the metrics gathered in the production to know, did they stop using because of their social awkwardness or something else. This is really just our guess but from our own experience we can see that. From the data itself that we can gather, it’s like we know if people are using this feature inside not outside, and that’s where their use is for.

Participant 1: You also mentioned that it was good to focus on one thing at a time. If there was too much on screen, how did you decide what to focus on and how to limit what to focus on?

Oda: We assign priority for each type of announcement, and whichever we think is most important at the moment is something we describe first. Anything that becomes a danger to the user is the highest priority. Like they are near an intersection so we don’t want them to cross. They are very careful, but we still want to add extra caution. Also, the places you hover is also considered to be more important than things that we tell you, there’s something else on your left side or right side. I think for any apps, you can think about, what is the most important things even though there might be multiple stuff. For our very specific use cases, those were the ranking of what we thought is important, and we only describe the one that has the highest priority.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

Security can clash with development efficiency. Focusing on minimizing breach impact can be more effective than prevention. Dorota Parad argues for flexibility in compliance and collaborating with security teams to define practical protections. Limiting blast radius and using automation can boost security with minimal productivity loss.

At QCon San Francisco, Dorota Parad presented how to build secure software without sacrificing productivity.

Security can be at odds with a fast and efficient development process. Focusing on minimizing the impact of breaches can be more effective than trying to prevent the breach in the first place. In Ensuring Security without Harming Software Development Productivity, Dorota Parad explored creating a foundation for security without negatively impacting engineering productivity.

Parad suggested pushing back on security mandates, as they can hinder productivity. This starts with understanding where those mandates are coming from:

The job of a CISO and your security team is very rarely about security; they are there to ensure compliance. Contrary to popular opinion, compliance doesn’t just mean mindlessly ticking checkboxes, the checkboxes are just (one) means to an end.

It all boils down to crafting a narrative that will convince third-party stakeholders – auditors, regulators, insurance companies – that your company does a good enough job minimizing security risks, Parad said.

None of the security certifications or regulations are prescriptive; it is up to your company to define the scope, means, and implementation, Parad said. It can be a daunting task, so it may be tempting to optimize for the ease of audits and do something like force invasive MDM (mobile device management) software without considering how it will affect engineers’ productivity, she added.

If you want to get rid of some of the more annoying mandates, you need to start a dialog with your security team and help them craft that convincing narrative they’re after, Parad suggested. This means documenting how you think about risks in your area, what you’re doing to reduce the blast radius of breaches, what levels of protection you have in place, and how you’re minimizing the impact of incidents.

Parad explored what can be done to minimize the impact of security breaches. She gave the example of a common threat: a malicious actor getting their hands on one of our engineer’s cloud account credentials:

What’s the worst that can happen here? If we applied the principle of bulkheads, then those credentials are limited in scope to a single cloud account, which may or may not host our production environment.

Parad mentioned that if we utilize modern software development practices, the access would be limited to read-only and innocuous configuration changes, since resource creation and deletion would be automated and only permitted as part of CI/CD pipeline.

If that account includes access to a database containing user data, and if we applied proper encryption, the data is effectively useless to the attacker, Parad added.

Trying to prevent the incident would be a prohibitively costly endeavor, involving multiple remediations to account for all the different attack vectors, Parad said. Limiting the impact is a holistic solution that doesn’t take as much effort or cost, and often comes with additional benefits of increased robustness, she concluded.

InfoQ interviewed Dorota Parad about how security and engineering productivity can go together.

InfoQ: What’s your approach to pushing back on security mandates that hinder productivity?

Dorota Parad: You can only push back on mandates if you have an alternative way to minimize security risks. This is where the BLISS framework (bulkheads, levels, impact, simplicity, and pit of success) helps, by offering an alternative that doesn’t get in your engineers’ way. With Bliss, you can make your security strategy almost invisible to the engineers while embedding it deep into the culture at the same time, Parad said

InfoQ: Can a CI/CD pipeline be considered a security practice?

Parad: This sometimes raises eyebrows among security folks, but yes, I consider a CI/CD pipeline a security tool. Implemented properly, it severely reduces the risk of malicious code ending up in your production.

A typical build/deployment pipeline involves increasingly strict levels of protection the closer to production the code gets – we start with git access controls to make a commit, then developer credentials to create a pull request, we have automated testing that may catch some issues, and finally a second set of credentials and a human review to merge. That’s a very powerful way to minimize security risks.

InfoQ: How can we increase security with a CI/CD pipeline?

Parad: Every single piece of code needs to go through that pipeline in order to reach production, no exceptions. No manual tinkering to push the build through, no bypassing of steps, no logging onto the servers to copy files or run some scripts.

The only way to achieve that in practice is by keeping your CI/CD pipelines healthy and robust, so that they only fail when something is truly wrong. Flaky pipelines are the enemy of both security and productivity.

Posted on mongodb google news. Visit mongodb google news

Welch & Forbes LLC boosted its stake in MongoDB, Inc. (NASDAQ:MDB – Free Report) by 27.3% in the first quarter, according to the company in its most recent disclosure with the Securities and Exchange Commission (SEC). The fund owned 30,948 shares of the company’s stock after acquiring an additional 6,630 shares during the period. Welch & Forbes LLC’s holdings in MongoDB were worth $5,428,000 as of its most recent SEC filing.

Other large investors also recently bought and sold shares of the company. Cloud Capital Management LLC acquired a new position in MongoDB in the first quarter valued at $25,000. Cullen Frost Bankers Inc. increased its position in MongoDB by 315.8% in the 1st quarter. Cullen Frost Bankers Inc. now owns 158 shares of the company’s stock valued at $28,000 after acquiring an additional 120 shares during the period. Strategic Investment Solutions Inc. IL purchased a new stake in MongoDB during the 4th quarter valued at approximately $29,000. Coppell Advisory Solutions LLC lifted its position in MongoDB by 364.0% during the 4th quarter. Coppell Advisory Solutions LLC now owns 232 shares of the company’s stock worth $54,000 after acquiring an additional 182 shares during the period. Finally, Aster Capital Management DIFC Ltd purchased a new position in shares of MongoDB in the 4th quarter valued at approximately $97,000. Institutional investors and hedge funds own 89.29% of the company’s stock.

Insiders Place Their Bets

In related news, CEO Dev Ittycheria sold 25,005 shares of the stock in a transaction dated Thursday, June 5th. The shares were sold at an average price of $234.00, for a total transaction of $5,851,170.00. Following the sale, the chief executive officer owned 256,974 shares in the company, valued at $60,131,916. This represents a 8.87% decrease in their ownership of the stock. The transaction was disclosed in a legal filing with the Securities & Exchange Commission, which is available through this hyperlink. Also, Director Dwight A. Merriman sold 2,000 shares of the stock in a transaction that occurred on Thursday, June 5th. The stock was sold at an average price of $234.00, for a total value of $468,000.00. Following the completion of the transaction, the director directly owned 1,107,006 shares of the company’s stock, valued at $259,039,404. This trade represents a 0.18% decrease in their ownership of the stock. The disclosure for this sale can be found here. Insiders sold a total of 32,746 shares of company stock valued at $7,500,196 in the last ninety days. Corporate insiders own 3.10% of the company’s stock.

Analyst Ratings Changes

A number of research analysts have recently issued reports on MDB shares. Bank of America boosted their price target on shares of MongoDB from $215.00 to $275.00 and gave the stock a “buy” rating in a research note on Thursday, June 5th. JMP Securities reissued a “market outperform” rating and issued a $345.00 price target on shares of MongoDB in a report on Thursday, June 5th. DA Davidson restated a “buy” rating and issued a $275.00 price target on shares of MongoDB in a research note on Thursday, June 5th. Macquarie reiterated a “neutral” rating and issued a $230.00 price objective (up previously from $215.00) on shares of MongoDB in a research report on Friday, June 6th. Finally, Wolfe Research initiated coverage on MongoDB in a report on Wednesday, July 9th. They issued an “outperform” rating and a $280.00 target price for the company. Eight research analysts have rated the stock with a hold rating, twenty-six have assigned a buy rating and one has given a strong buy rating to the company. According to MarketBeat, the stock presently has an average rating of “Moderate Buy” and a consensus price target of $282.39.

Check Out Our Latest Research Report on MDB

MongoDB Trading Up 0.5%

NASDAQ:MDB opened at $209.64 on Thursday. The firm’s fifty day simple moving average is $201.07 and its 200 day simple moving average is $213.37. MongoDB, Inc. has a twelve month low of $140.78 and a twelve month high of $370.00. The firm has a market capitalization of $17.13 billion, a price-to-earnings ratio of -183.89 and a beta of 1.41.

MongoDB (NASDAQ:MDB – Get Free Report) last issued its quarterly earnings data on Wednesday, June 4th. The company reported $1.00 earnings per share (EPS) for the quarter, beating the consensus estimate of $0.65 by $0.35. The company had revenue of $549.01 million during the quarter, compared to the consensus estimate of $527.49 million. MongoDB had a negative net margin of 4.09% and a negative return on equity of 3.16%. MongoDB’s revenue for the quarter was up 21.8% on a year-over-year basis. During the same quarter last year, the company earned $0.51 earnings per share. On average, analysts predict that MongoDB, Inc. will post -1.78 earnings per share for the current year.

MongoDB Profile

(Free Report)

MongoDB, Inc, together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

See Also

This instant news alert was generated by narrative science technology and financial data from MarketBeat in order to provide readers with the fastest and most accurate reporting. This story was reviewed by MarketBeat’s editorial team prior to publication. Please send any questions or comments about this story to contact@marketbeat.com.

Before you consider MongoDB, you’ll want to hear this.

MarketBeat keeps track of Wall Street’s top-rated and best performing research analysts and the stocks they recommend to their clients on a daily basis. MarketBeat has identified the five stocks that top analysts are quietly whispering to their clients to buy now before the broader market catches on… and MongoDB wasn’t on the list.

While MongoDB currently has a Moderate Buy rating among analysts, top-rated analysts believe these five stocks are better buys.

View The Five Stocks Here

Unlock the timeless value of gold with our exclusive 2025 Gold Forecasting Report. Explore why gold remains the ultimate investment for safeguarding wealth against inflation, economic shifts, and global uncertainties. Whether you’re planning for future generations or seeking a reliable asset in turbulent times, this report is your essential guide to making informed decisions.

Get This Free Report

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Article originally posted on mongodb google news. Visit mongodb google news

Posted on nosqlgooglealerts. Visit nosqlgooglealerts

Article originally posted on InfoQ. Visit InfoQ

Transcript

Renato Losio: In this session, we’ll chat about designing for defense and architecting APIs with Zero Trust principles.

I would like just to give a couple of words about this panel and about myself, and clarify what we mean by designing for defense and what’s the topic today. API security has moved in the last decade from being, I wouldn’t say optional, but not that important. I’m old enough that when I started playing with APIs it was not on top of our mind, to be now essential, and is now a primary front in our system defense. Traditional security models are not enough anymore and that’s where Zero Trust security comes in.

My name is Renato Losio. I’m a cloud architect. Also, I’m an editor here at InfoQ. I’m not the expert here, the experts are our four experts coming from different companies, different sectors, and different backgrounds. I’d like to give them the chance to discuss the topic. Just a couple of more words about what we are going to discuss. We’re going to explore why APIs are the center of today’s security threats and how we are going to apply Zero Trust principles to protect them. I would like to give a chance to each one of our four panelists to introduce themselves, and share their professional journey in designing for defense and why they’re here today.

Ben Bridts: My name is Ben. I’ve been working as a Cloud Engineer, Cloud Architect for a little over 10 years. Specialized in AWS, so I’m also an AWS Community Hero. My background is in operations, which means that the longer I do this, the more security things I have to do, the more learnings on architecture, the more compliance, sovereignty becomes important.

Katie Paxton-Fear: I’m Dr. Katie Paxton-Fear. I am a Principal Security Researcher at Harness. My career journey I often say is that I used to make APIs and now I break them. I’m an API hacker. I find vulnerabilities in APIs before the bad guys can. I show companies how you can secure your APIs, be more effective. I write that a lot as technical content, webinars, blogs, white papers, all to really improve API security for everyone.

Nivedita Murthy: My name is Nivedita Murthy. I’m a Senior Staff Consultant here at Black Duck. I’ve been in this industry for 16 years now working in all areas of AppSec. Currently helping our clients improve their application security program by providing consultation on strategic initiatives out here.

Zsolt Németh: My name is Zsolt. I’ve been in cybersecurity for 16, 17 years. Started out as a developer of algorithms or symmetric ciphers, mainly. I got into the cloud space about 10 years ago. What we are doing now is actually using moving target defense for strengthening security postures, or hiding the attack surface against the attackers.

What Is Zero Trust Security?

Renato Losio: I’d like to basically start with the most basic probably question, but just to really set ourself on the same page and as well give a feeling of really what we are talking about. What is Zero Trust security? What is so important for APIs?

Katie Paxton-Fear: Zero Trust started out really as a methodology for securing networks and infrastructure, but it’s become a lot more than that. It’s become a general ethos around how we should think about security. It’s quite straightforward. Zero Trust is about assume breach, assume you’ve already been compromised and secure your assets accordingly. If you’ve got something like APIs, obviously they’re highly connected.

If one API is breached, how do you protect every other API, for example? It’s very much thinking about like principles of least privilege. Making sure that nobody or no API or no API user has more privileges than they should. It’s about making sure that any PII you have is protected appropriately with whatever precautions you want to put in place, like encryption, for example. Really, what we’ve really seen in the past few years is it’s becoming the way folks think about security and the way folks start to pull the pieces together around security and what good security looks like.

Renato Losio: I don’t know if you want to add anything else to the topic or maybe clarify what you think is important for APIs.

Zsolt Németh: The short version is, assume compromise always. That’s it. APIs, 10 years ago, it was like a vent on a house. Right now, this is the front door, and that’s why it’s important, because the side window or the garage, whatever, you can get in easily. Right now, it’s actually much worse because this is basically the front door the attackers are usually getting in. That’s why you need to basically defend it. Again, before that in the architectures, there were something like safe zones or whatnot, but that’s not true anymore.

Challenges of Applying Zero Trust, with no Background in Security

Renato Losio: I have a question as a practitioner myself, that is not coming from a security background. I’m old enough that every few years, I hear that things are getting worse and it’s getting harder and it’s getting more important. I find it as a developer always a bit scary as I don’t feel really enough. What are the main challenges for a software architect, software developer to applying those principles to get to the front, to protect that front or make it so essential in the technical journey? What are the challenges you see?

Ben Bridts: Like everything with software, there are so many options. There are so many things to get right, that it can be challenging to know where to start. It can be challenging to know what exactly you need. There’s a challenge in some way, like the thing that Katie said of like assume compromise, helps with that as well. You have to assume that it’s untrusted.

I think the main challenge is like, I have this API, like I’m used to this specific framework that I’ve been using for so long, like what’s my first step to start securing my APIs? Am I going to focus on more general approaches? This is an example. It’s not what I recommend. Like, am I looking at firewalls and stuff like that, or am I looking at authentication, authorization, like complete new policy languages? There’s a whole spectrum of things that all fall within the same thing, that knowing where to take your first step to start securing your APIs and to build something that you can comfortably say, this is where I trust, or I know that even though I don’t trust anyone, this is a valid request that I can actually act on.

Renato Losio: What do you see as the main challenge for someone like myself or a software architect that is not coming from a security background?

Nivedita Murthy: I think it’s the not complexity that you add when you start thinking from a security side. Let’s take, for example, a SELECT * from a table. It’s easy to write that query. There’s no filter. It gives me all the information. It’s easy to send it out. It’s easy for the developer to write it. When we start telling them, you cannot send the entire table. You need to put in filters. You need to put in checks. They need to add some filters out there. Adding that, especially in terms of an API, gets a little bit tricky, gets a bit more difficult. That’s where engineers say, security is making my work difficult here.

It’s just adding more time, more complexity to the problem out here. I just want to give my API out and make this functionality available to everyone. When security comes in and says, no, you cannot just make all the data available immediately to everyone, you have to put in certain checks. That same data has to be split into four different APIs, or maybe verify that the request is coming from the right place, or add in limits to the number of records coming in. That’s where the developer thinks it’s getting a bit more trickier, a bit more complex, a bit more difficult for me to just send out this functionality in the next two, three days that they have been given to set up the new API.

Incentivizing Devs to Apply Zero Trust Principles, Upfront

Renato Losio: I see that when you mention the extra effort is something that everyone was nodding. That’s actually the feeling I have sometimes as a developer, that always that concern, instead of saying, that’s one of the key aspects that I cannot get the API wrong. I cannot break security. Day one is like, I see that as a burden. I’m thinking as well, when I build something simple, like I’m using even a manual service, like an API gateway or whatever else, and I feel like, I can’t just do it. I can’t just put it out there. How do you interact with a developer that feels that applying those principles upfront is going to slow down development, or I’m just doing my first MVP, so it doesn’t really matter, but be sure I will take care of that later on. Why is that wrong? How should they adapt that?

Katie Paxton-Fear: I think it’s really challenging, especially for APIs in particular, and I’ll explain why. APIs as a product are very developer-driven. Unlike other products where we might have something like user requirements, and we’re thinking about customers. When it comes to APIs, our customers are developers, they’re us. They might literally be us, as in, we might be developing the next application that connects to that API.

One of the problems and the challenges there is that when developers are in a position where they’re being told to add security, if they’re being told by the security team, it’s like interfering with their child. This is something that they’ve designed from the ground up that meets their requirements, that they’re in complete control of, and the first thing we do as a security team is take it away from them. I can see how any developer would get really annoyed about it. It’s normal for people to get annoyed. I think for us as security teams, we don’t really consider the developer perspective that often. We’re so much thinking about security. We are in a world of security vulnerabilities. We’re reading the news about security breaches. Developers aren’t in that world. It’s up to us to be a resource for them. Not to be the person going, “No, you can’t do that. You can’t do that. Stop what you’re doing”.

Instead be, “You want to do that? Let me help you. I will do this. I will take on the cognitive load of figuring out the security side of this so you can focus on what you’re doing and what you’re best at”. I think really one of the main challenges I see in a lot of teams is that when APIs, particularly if they’re developed to be initially internal only, they do not have the same stringent security because it’s internal only. Who cares? For something like implementing Zero Trust, that’s so key. If your developers are in a position where they’re going, “It’s internal only, so it doesn’t matter. It’s for me and me alone, so it doesn’t matter. Stop telling me how to do my job. I’ve worked in this industry for 15 years. I know what I’m doing”. You have this recipe for a real breakdown in communications.

My first advice for any team is to go buy your developers donuts. Give them something. Give them a reason to want to speak to you. Stop telling them no. Start saying yes. Develop that friendship because that is where things will go wrong, that relationship between developer and security team.

Ben Bridts: For developers listening to this, it’s a two-way street as well. Security is not there to block you. We want everything that Nive said of rate limiting and stuff like that. Good security is good design. You want it in your API. Problems arise if you’re like, build everything first, and then go to security, trying to push it through in one day and now we need approval. If you come to security on day one, say, I’m going to build an API. Maybe you haven’t thought about this is going to be internal or external or things like Zero Trust. Maybe there’s a way to build that in from the start and not have that at the end.

Katie Paxton-Fear: As a security team, that’s where you should be. You need to be in the design phase. You need to be there. You need to be that resource, so they don’t have to think about there.

Zsolt Németh: However, the problem is like, we’re talking to a lot of CISOs, a lot of security teams, and they usually just tell the developers that, I’ve got this dashboard. It’s pretty easy to use. Why don’t you just do it? It’s super easy. There are three big problems. One is, developers are definitely not security guys. You need to figure out, not just how to talk to them. You have different priorities than us. Ours is security. We kept trying to get rid of that, like shift left and whatever. Like whatever happens down there, that’s the developer’s problem, or the head of DevOps, or DevSecOps, or you name it. It didn’t work.

The other problem is you have different priorities. The first thing, when I talk to a developer, the application has to work. Then, load testing, then resilience, then UX, and maybe then comes security. By that time, that’s just too much of a burden. As Katie said, security guys should help or could help, not just by buying donuts, but obviously going further and just start a conversation. That conversation is not really happening, according to our experience. That’s the biggest problem because you are there, they expect you to solve something which you don’t even have an idea about, and that causes bad luck.

Nivedita Murthy: I think Zsolt and Katie, all of you have mentioned about providing incentive in a way to the developer. What we do over here also is that when we provide them a security report, a penetration test report, for example, we always highlight first what are the good things that we found in their application, because you don’t want to go straight away for the bad points. You want to actually say to the developers what good did they do. They’ve actually, inadvertently, without them actually thinking maybe, they have secured their application. You want to point that out first that these are the good things in your application. You’re protected against authentication attacks, or authorization attacks, or maybe some validation attacks out there. You’ve done that and that’s great, but let’s also focus on these areas in your code which may need some improvement, may need some curing.

One of you mentioned over there that it should not be on the developer to think so much about security. It is the security team’s responsibility. That’s why this question should come at the design phase itself that, how do you design this application, so that it’s easier for them to just push out those APIs which are inherently secure, and does not give out the information that it’s not supposed to give in the first place. Pushing this requirement in the design phase itself helps in the long run. It reduces the effort involved in developing these APIs as well.

Internal APIs vs. External APIs: What’s the Difference?

Renato Losio: When you mentioned about internal versus external APIs, the high-level concept is very clear to me. As well, I can say, I have many different microservices all talking with their own API and different teams talking together. Sometime I ended up in a discussion that there was a bit of a mismatch what we meant. The other person meant internal means only private IP. There’s no public IP there. Some other really much more extended concept like, by internal I meant the specification was just for some internal product. How do you see that? When you meant internal, you meant just nothing in the public space, or what’s usually the definition of an internal API?

Katie Paxton-Fear: I meant both of them, because there is no really clear definition of what internal means. Obviously, with the kind of infrastructure we have at the moment, especially around mobile apps. Mobile apps are essentially just APIs at the end of the day, they all connect via APIs. For an organization to have a mobile app, you also need the API, that can’t be just restricted to your network. It has to be online. You don’t have to provide documentation. You don’t intend anybody else to use it, but your mobile app, the API still needs to be there. Often, people refer to that as the idea of an internal API, because as you say, only developers have access to the API docs. Then you have APIs that are really designed to be internal only, so they are going to be restricted. I will say, as an API hacker, that is rarely true. I have found many internal APIs that are publicly available on the internet.

Renato Losio: Through a proxy or whatever else, yes.

Katie Paxton-Fear: A proxy or you can usually pivot as well. Like you just need access to one API, then that will make requests on your behalf. Or just people are like, it’s not on a domain name, if it’s on an IP address, for example, but it’s still available. Or they’ve got references to it in the code, like in JavaScript, even if they’re not making API calls directly. That’s also another fun way to find internal only APIs. This goes back to why Zero Trust. Like, assume those APIs are compromised. Assume I can already see them. How does your security strategy for those APIs shift when that is the case?

Ben Bridts: I fully agree with that. I think the distinction of like internal versus external is an access level, not just for APIs, but for everything, is very risky. In terms of APIs, talking about like, this is a user API versus an administrative API, whether that’s callable from inside or outside, like own apps or different apps, it doesn’t matter. It has certain things it can do. That’s the important part. That will drive, how are we going to protect it? What are the policies we’re going to apply to certain endpoints?

Admin APIs vs. User APIs

Nivedita Murthy: You mentioned about admin API versus user API. APIs were introduced to just make it simple and easier for applications to interact or developers to get information from applications, just interfaces. Do we really need an admin API for that matter on an API level, is that necessary in the first place?

Ben Bridts: No, I think this is more of me putting on my developer hat and how I think about data models in the sense that both are accessed by principles that are going to be doing something. In some cases it’s going to be very clear, this principle is my end user, my customer that’s going to be acting on their data and need their permission model. That’s what I call the user API. It’s end user facing API. Whether that’s internal, external, where it is coming from, it’s doing something for the end user directly.

Then it’s like, I need reporting on that. Maybe I need a support team. Not even how I design my microservices, but like project concept. That’s more of like admin level stuff. That’s going to be acting on multiple users possibly, or impersonating a user, or all that kind of more risky stuff, more traditionally what you call like an internal API. It will still need to be authenticated to a certain user. It’s not like admin that can do everything. A certain support person can do certain support things.

Katie Paxton-Fear: Do we need an API to do that, because we’re talking about Zero Trust. You want to limit access. We want to also limit in terms of how the application can be accessed with elevated privileges. Would it make sense to have at an API level or just give an interface an actual web application, so it doesn’t go through an API. That’s from a design perspective.

Ben Bridts: For me, everything is an API. If that’s a PHP app that’s rendering web pages or that’s like a fat client, it’s an API. It’s doing something somewhere.

Where Should a Developer Prioritize?

Renato Losio: One of the challenging parts as an architect, as a software developer in general is, we say security should be part of implementing and designing robust and proper APIs, at least in theory. Things about rate limiting or whatever else I’m thinking about, or zero security, whatever else I want to implement. Somehow when I implement my API, I’m thinking about my problem. I think it’s not against the security team or against someone else. It’s just, I want to implement my feature A, that is, add a contact to the user, post something somewhere, and I feel like reinventing the wheel if I have to do at my layer, at my level. Either I’m using something that is out of the box, a tool or something that is doing it for me and someone else is managing that, possibly. Where should I worry? As a developer, should I think about rate limiting or is it something that comes later? Day one, where should I start from? Because if I have to implement it myself, probably it’s more complex than my API somehow. I feel like I’ve reinvented the wheel.

Katie Paxton-Fear: I can tell you about my very first vulnerability I ever found. It was on Uber, and I found this vulnerability. It was in a major Uber product. It’s long since resolved now. I’ve spoken about many times. It’s not sensitive. The way I found that is because I saw a RESTful API that was implemented correctly. As a developer, I knew that RESTful APIs are supposed to use PUT and DELETE. They’re supposed to use the different HTTP verbs. Have I ever developed an application that ever uses those? No, everything is POST and GET. By seeing that in the wild and seeing it on this application, I’m like, this is done correctly. There is no way a human wrote this. Surprise, the human didn’t write it. It was an automated tool, which then didn’t add the required authorization checks and actually authentication as well, because it was essentially just a generated API.

I see that all the time now of people trying to take a shortcut, especially nowadays you’ve got AI and vibe coding. I think tools are great. They are really great for allowing you to do things more effectively and more efficiently. I think you got to know some of the principles yourself as well. It’s not enough to just rely on them and just assume, the tool will handle everything so I don’t need to think about it, because the tool is dumb and you’re the smart one in the room.

Renato Losio: All my assumption of just putting some managed services and lead the security for that in front of my simply developed API is already gone.

Zsolt Németh: What I wanted to add just briefly about rate limiting. Obviously, it’s a heaven for attackers, so like DDoS, brute force, whatever, we call it the architectural sins. You need to be aware of that. As a developer, rate limiting isn’t easy stuff, like how you separate the data planes and the control planes. What we see at most of the customers, like they log everything without protecting the logs. You can basically just get there and mine your information out, or use AI to mine your information out. It all gets back to a bigger problem from the developer perspective, whether the API is ready or you need to write it from the ground up, because if it’s ready, you need to put the work in to redesign the whole thing. That’s a lot of overhead, which most of the CISOs or CIOs don’t like, because that’s additional money to be spent.

The Most Common API Vulnerabilities

Renato Losio: I’d like actually to go back to what Katie mentioned before, the case of Uber. I don’t want to go too much into detail of a specific case. I’d like to scare our developers a bit. Without necessarily naming a specific company, but share common API vulnerabilities, what are common things that usually developers don’t think about, apart from authentication, of course, that is the first, probably the only thing that we think about, or which method we use. One guilty one usually is POST, whatever it is, for GETs. That’s it. I don’t know if you have any story, anything you want to share that could tell us how to go to the next level and how to think a bit more about what we do. I had the feeling before you mentioned as well, don’t expose anything that you don’t need, like an admin, but if you have anything you want to share.

Nivedita Murthy: The one commonality that I saw in all the breaches that have happened so far, they’ve all collected information about people in the database, and sensitive information specifically. Today data is valuable. It is money, more than actual money. Sometimes data is money. It can be used for nefarious purposes, going from phishing, scamming, or whatever, but you can sell data to someone else for whom that information is valuable. I also have used APIs a lot to write my own scripts to automate stuff.

One of the easiest things to do is just call an API, get information about a certain thing and just push it into an Excel sheet, just export it out. This is basically data scraping. That is one thing that happens regularly with APIs. You’re just pulling information, pushing it into a file or into a database. You do that continuously. When you are an engineer developing an API, you need to think about this. What are the different ways a malicious user would basically get information out of my application and push it out somewhere else? Does that information need to be out there in the first place? From the U.S. side, does the SSN number have to be on an API? Does the address have to be on an API? Is that information necessary for the API to process? Those are the things that you need to think about.

Katie Paxton-Fear: I 100% agree. I think what separates out a lot of API attacks from other attacks that we see in the media is how targeted they are. If you look at something like ransomware, it is targeted. Criminal gangs will go after specific industries and they’ll go after the entire gamut of those industries, a bunch of different companies in that industry. However, the difference between that is that it’s often very opportunistic. There’s a vulnerability or there’s a known flaw that they can exploit and get the ransomware on the computer, or they’re just sending a bunch of phishing emails and then whichever company clicks it and runs the malware, that’s how they get infected.

One difference we see in API attacks is that the kind of attackers that go after APIs, they know what they’re doing. They often know about things like what the API does. They know that wider context. They know it’s got a social security number. They know it’s maybe got credit card information in there. They know that. They understand the API. They’re understanding the attack surface. Often, they can actually understand your API attack surface better than you do. What’s important to know is that most API security vulnerabilities are not ever going to be massive vulnerabilities. We’re never going to see the API security vulnerabilities on pure technical merit alone. It’s not like the hardware security people. Most API security mistakes are that little mistake, small mistakes.

In the entire library of an entire API where you have hundreds of endpoints, you have thousands of users, you have millions of requests every day, you just cannot spot the malicious stuff among all the noise. It might be the difference between one line of code and two lines of code. Where I see the most as a hacker is often silly little mistakes made in things like authorization. There’s no if statement to check if a user owns that object before they start to edit it. There’s no check to make sure the user’s logged in. Those are, again, silly little mistakes. They’re not massive, huge fundamental shifts in the way we think about technology. They’re, “I just didn’t write that”, kinds of mistakes.

API Monitoring

Renato Losio: I was thinking, as Katie just mentioned, sometimes there’s little mistakes or little things. In a large number of APIs, I might have an entire SDK, hundreds of APIs, whatever it is. How do I monitor? Do I monitor my API for that? I’ve built my nice app. Let’s go back to the example we had at the beginning of an app. Maybe I haven’t even published my APIs, but still, there’s something there. What should I do? Should I do something?

Zsolt Németh: It depends what you want to do. There are lots of open-source tools, but Harness is one of them, and so on, what you could use. From my perspective or our customer’s perspective, yes, we can put Falco in it for runtime container security, but more basic stuff. I think it’s mandatory now everywhere to sign your container, so that you use Cosign, or something like that.

Renato Losio: The way I see it, as a developer myself, either I’m using some managed tool, whatever, it’s from a cloud provider or something else, where I have some API, build my API, I build just my logic. Then the only real monitoring that I’m doing sometimes is just on a number of requests, error rates, or whatever. That as well doesn’t tell the full story, because as Katie mentioned, it can be a single mistake that opened up. Not necessarily I’m going to see a huge spike of errors or whatever, and my data might be out there. I was just wondering what I should do as a first step.

The Danger of a Malicious API Structure

How dangerous can an API malicious structure be for a company?

I assume it can be as malicious as not having the company anymore.

Nivedita Murthy: Think about traversal. We have something called as, you jump from one box to the other, the same thing can happen with an API as well. I think Katie mentioned an example where she was able to pick up an internal API from an API that was external. How we look at the structure is, is it sending information about an internal API that is not supposed to be available to other users, or, are you able to jump from one API to the other without verification? Maybe you need elevated privileges to use a certain API, but if you jump using one API to the next one, does it allow you to go over there? You have to think about, in that sense as well, as to, is the entire API design a faulty way by allowing to go places where you’re not supposed to go in the first place.

Katie Paxton-Fear: There’s two things to think about. I’m going to answer both of them because I’m selfish. If you’re wondering, do I have a rogue, malicious API? Has an attacker deployed an API on my systems for their own usage? That is bad-bad. The second attackers can deploy anything on your systems, the entire system is compromised, like full stop. If that is happening, you need to turn it off at the wall, like switch it off, do a full recovery, because you just don’t know how deep they managed to get into your infrastructure. If the question is not necessarily, is the API malicious, but are malicious users using an API, how bad can it be? It’s like saying, how long is a piece of string? It really depends on what that API is doing, what sensitive data it’s handling, what sensitive processes it’s handling, because it’s not always about data. Sometimes it’s about processes as well.

Somebody asked me once, they were like, is API security a million-dollar problem? I’m like, it depends on how many APIs you have and how valuable they are to your business. APIs now often are such big drivers for organizations to grow in terms of customers, to provide them as a product, just to enable people to deeply connect to them. Look at the backlash when Twitter removed its API from being able to be public and people had to pay for it. That caused massive backlash. APIs now often become the crown jewels of how a business functions. If you’re wondering, how bad can API security be, what industry are you in? If you’re in finance, maybe it’s financial losses, maybe it’s loss of customer trust, maybe it’s a further breach where they use APIs as an initial access point and then pivot into other systems.

Really, APIs are so dependent on the context in which they run, and that really makes them unusual when compared to other web applications as well. I can’t tell you how bad it is unless you tell me the company you work for, and then I’ll tell you as a hacker, here’s what I would do and here’s how I would target it and here’s what I would go after, because this is what I would see as valuable.

Open-Source Security and Monitoring Tools, for Devs

Renato Losio: Zsolt before mentioned some open-source tools, I would like to go a bit deeper in that sense. If there’s any tool that you think, not as a security expert, but a developer should be aware of, or should be familiar with, or should use to protect or even just to monitor, whatever. I don’t know if you have any recommendation.

Ben Bridts: It’s a hard question because there’s flaws with a lot of them. I think knowing about JWTs and how they work and what the pitfalls are there is probably the one that’s going to give you the most value. Wherever you’re working in the industry, you’re probably going to have to deal with that at some point.

On the other hand, if you want to look at what would be good authorization design or a good way to secure your API, I’m not the biggest fan of them necessarily. Very specifically, but I assume this exists in other clouds as well, for AWS, looking at how their Signature Version 4 signing works, for example, and how other people use that to imitate S3 in some cases. This is cool to have in your back pocket of how you can design APIs to only trust a request one time. I think it’s very useful and very good to know. I’m not sure if that is something that I would be able to implement at my day job as a developer, to come up with, now we’re going to full sign every request and have nulls on there, like you can only do it once. It’s going to be valid for a minute and then we throw it away. I would start with JWTs.

I also would really recommend looking at using a library for that. I think Google has a good one in Tink for that, that turns off all the things you don’t need. Turn everything off. There are so many things in there that you don’t need, just turn it off. Only use the specific thing you need.

Modern Programmatic Techniques of Securing APIs

Renato Losio: What is the best modern programmatic technique of securing an API? Does it depend on the type of API? What about two or something else?

Zsolt Németh: At a high level, I can start with that. How I would do it or how our guys are doing it here is that they’re not kind of collecting tools. We have OVAL. We have Kyverno. We have Oathkeeper. Basically, they focus on the weakest spots of the architecture, which either they find or we tell them that this is going to be a problem, have a look at it, and solve that specific problem first. Obviously, you can pre-scan your API pre-deployment. You have tons of tools for that, and so on. Basically, I think you should solve the problems first and not finding the problems, and trust the security guys or trust the security team to actually point out these problems first.

How to Identify a Compromised API

Renato Losio: Do you want to answer the one-million-dollar question of how to identify that your API was already compromised?

Katie Paxton-Fear: It’s weird because as an API hacker, I don’t often see that. I often am on the outside looking in at APIs. Some things to be aware of is, one, large amounts of data being transferred out of your organization. That’s the standard one. You’ll see it a lot mentioned because nowadays, we are seeing really large data breaches, as Nivedita said earlier. We are seeing people going after PII especially, usually to use in other kinds of attacks.

Other things to keep in mind, though, if you’re working in an industry, knowing what’s happening. In fact, the biggest recommendation I have to any developer ever about how to learn about API security or just security in general, go to a security conference. Go to your local BSides, go to DEF CON, go somewhere like that, become immersed in that world, and you will probably know what to look for. You’ll be able to see how that interacts with the system you have because you’re an expert in that, way more about than anyone else is in terms of how your organization is laid out. Actually listening, these are the kinds of attacks we’re seeing.

These are some of the IOCs, Indicators of Compromise that we’re seeing, like check these out. I think the number one mistake any organization makes is just doing nothing. When it comes to API security, it’s often left as a nice to have. People aren’t actively investing in it, so there’s not an awful lot of tools that can give you that information. There’s not in-depth monitoring and logging for APIs that you can easily get that’s free and open source. It’s a very specialist solution. With that, it makes it challenging, because any indicators that I could give you, you would have to have the right setup to look for them, so looking for them in the first place, having a process that you could go through those logs, review them, see what they say, go through that, how would I investigate this kind of attack? Creating those runbooks can often be far more valuable than any kind of individual indicator that I could give you, for example.

Renato Losio: If I understand, I need to have the logs. I need at least to keep an eye on my networking activity.

Nivedita Murthy: As a developer, especially someone who’s working on APIs, you definitely have access to Postman. Start off with, just try and manipulate the values that you’re sending to see how it reacts. Don’t do it like normal user functionality, I think, as a malicious user, maybe. Add an extra character, add too many numbers, for example, or just remove a filter and see how your own API reacts to that scenario. That’s your first step to testing out, is your API vulnerable to malicious attacks? Like Katie mentioned, this is a specialist scene on how to monitor whether it’s being vulnerable to, let’s say, multiple attacks out here.

One thing I could provide is, there is a page on the OWASP website. When I say OWASP, it is Open Worldwide Application Security Project, which gives a lot of free resources and open-source resources for securing your application, and also guidance on how to do that. There’s an entire page which lists out both commercial as well as open-source projects that’s dedicated to API security. You can pick out one of them, and see how it works, try and use it, and see whether your API is secure or not in certain manners. There are limitations to each tool for sure, but you can start off over there and learn how good is your API in terms of security versus how bad is it.

Resources for API Security

Renato Losio: What is a tool, what is even a paper, podcast, book, or even a conference, as Katie mentioned, that you recommend every developer should not miss? I don’t know if you want to give an advice, an idea for, go out of this roundtable, listen to this podcast or go join this conference, or something.

Ben Bridts: I help organize fwd:cloudsec in Europe, so I’m just going to mention that. I really like that one. Look for security-specific conferences. I think the OWASP thing is also a good thing to look at. I think we maybe should pivot back to APIs and Zero Trust, but the base vulnerabilities of sanitize your inputs and know what you’re getting. Especially in this time, don’t trust your client. Anybody can open your app and see what’s in there. Those things are also still going to be out there. That’s not new. We should just keep talking about it until more people fix them.

Zsolt Németh: I would go to the conferences as well, or if you’re here in the Bay Area, so a lot of meetups, but probably that’s happening everywhere as well. I know in the Netherlands, it’s a lot of activity going on in terms of security, not specifically an API, but more like Zero Trust, I’m sure.

Understanding Zero Trust in API Design

Renato Losio: As I understand it, Zero Trust in API design is primarily a concept with tools supporting each aspect, like assume breach maps to short-lived token, or never trust, always verify, map to OAuth on every API call. Do you have any comment about it?

Katie Paxton-Fear: When it comes to Zero Trust, it used to be far more prescriptive of how to meet these. It’s become much more a lesser methodology and more a philosophy around how you do security. With that, the way you implement Zero Trust in your APIs as you’re creating them can look really different. If you go with assume breach, that can mean short-lived token. It can also mean, what other APIs does this API have access to? What other data does this API have access to? Ensuring that you have things in place to not just have short-lived tokens, but also to recognize a compromised API to do something like rotate secrets, or something like that. When we talk about the idea of never trust, always verify, again, you can do that in multiple different ways. It really does depend on that API. I would say for Zero Trust, like practically how I would implement Zero Trust in an API, would be, follow the advice of assume breach.

Go through every single API and ask yourselves, if this was breached, what would happen? What would they do next? Even better like, I think Nivedita is absolutely correct, learn how to hack. Have a go at hacking. Have a go at API hacking and have a look into what attackers can actually do to help give your team ideas. Also, it’s just fun.

For a lot of developers, you don’t often get to do something just for fun. I’ve actually had quite a lot of good experiences with developers of teaching them how to hack to get them more engaged in security, but also have them thinking about security and what an attacker could do. It’s really about getting in that mindset of an attacker. There are some good easy wins there. OAuth, easy win. Tokens, easy win. Having expired, like all of them are easy wins. Fundamentally, they are easy wins. They are first steps. They are baby steps. There is a lot more that you can do to really inhabit the philosophy of assume breach.

Resources for API Sec, and Security in General

Nivedita Murthy: To the previous question, yes, security conference. The other thing, listen to some podcasts which is outside of application security. I like to listen to something outside of my domain just to get some ideas as to how attackers try to do things outside of it, and maybe apply in my application. How can I do that same thing? Can I replicate that in a way in my application, or use the same method? The one which I enjoy is by Jack Rhysider. He talks to various people and their experiences, what they have encountered, how did they open up an application.

There was one where someone made free video game money out of the video games by just changing a value or something. That was fun to listen. Those same principles can be applied in API. I would definitely recommend just listening to some stories. You can listen to that on podcast. You can listen to over here, like this webinar, or going to conferences or even local meetups, and just talking to people within the industry about their experience and what have they been doing out there.

Ideal Starting Point in API Security

Renato Losio: Until now, I got super excited thinking about being always in a brand-new API, start from scratch, zero principle, all great. Now, I’m in my reality, day-to-day programming job, and suddenly I have my 200 APIs already there written in Java, .NET, whatever you want, with some database behind, some authentication already in place. I want to do something in the right direction. How do I tackle it? Just ignore it, start from scratch? What are the baby steps in this case when I have already something in place? Where should I start?

Zsolt Németh: I think I’ll just reiterate what I said a bit earlier. Start with the weaknesses that you already have, and fix them one by one. We won’t get to zero weakness anytime soon, but your security posture is going to be much more solid.

Ben Bridts: My first reaction is you probably know in the sense that like it’s your APIs, it’s like your bunch of things. The question is like, what are the things that you feel like this is important data that’s behind it, or this is something that’s going to be a problem if somebody does something wrong with it. Or the other side of it, like what’s the thing you haven’t touched in 10 years? You know where the bodies you’re hiding is in your closet. Start with that one.

Low-Hanging Action Items and Key Learnings

Renato Losio: What’s an action item for our audience? Give an advice of what you can do tomorrow as a first step to take the advice from today and do something tomorrow. It doesn’t have to be, change the code, can be even just read a book, can be, see a podcast.

Katie Paxton-Fear: Literally anything. You’re doing better than 10% of organizations if you do literally anything about API security. Most folks have their head buried way in the sand. Simply listening to this, you’ve already taken your first few steps. Now it’s just time to keep on walking.

Nivedita Murthy: This is the regular advice I give all my clients in general. Have an inventory of what you have. You will then realize that there’s something out there that you created 12 or 15 years ago, but never used it, but it still exists as of today. You might want to just do a cleanup of your inventory or your APIs. Just whittle it down to a manageable number of APIs that you can think of, and which one’s important versus not so important. Just create an inventory, have that list ready. I love lists, create your list of APIs here.

Zsolt Németh: I would do actually much simpler. Go to ChatGPT and ask for a detailed plan. No, I wouldn’t. On a serious note, I would start with reading because I’m old school and I like reading. I would basically read, even just horror stories of what happened with unintended APIs, or when people figured out that, there was a behavioral drift in our API, and they figured out nine months too late. There is no too late. I’ve seen a couple of CISOs being fired because they noticed something way too late, and the attacker dwell time was usually like 5 years plus, not to mention one. Basically, I just want to rephrase what Katie said, yes, anything. I would personally start with reading short and sweet stuff.

Ben Bridts: I have two things. The first thing is like, go have fun and poke around your stuff. I’m not a serious hacker at all, but what I do is every time there’s an internal app, like we have to reserve parking for somewhere, or there’s like, this is how you book a meeting room, and you get a mobile app for that. See how that works. You’re a developer. You can do things that they don’t want you to do. Reserve that meeting room that’s only for the director, or stuff like that. It’s a very fun way to learn how those things work and to see what’s available to someone who is not trusted with the thing. You get the device, like they don’t trust you, but you can do all those things. Secondly, go get those donuts from the security team. Just talk to each other. It’s really helpful for both sides.

See more presentations with transcripts

Posted on mongodb google news. Visit mongodb google news

MongoDB recently dropped its Q1 2026 results, and well … Mongo is back.

At $549M quarterly revenue (22% YoY growth), they’re proving something important: you CAN still grow 20%+ at massive scale.

Here are 5 top takeaways every B2B leader should internalize:

1. The “Growth Re-Acceleration” Playbook at $2B+ Scale

The Numbers: After moderating to 19% growth in FY2025, MongoDB bounced back to 22% in Q1 2026.

Why This Matters: Most companies see linear deceleration as they scale. MongoDB proved you can actually re-accelerate growth even at $2B+ ARR through:

• Product expansion (Atlas now 72% of revenue, up from 71% last quarter)
• Customer base expansion (2,600 net new customers – highest in 6 years!)
• Market category expansion (AI workloads driving new use cases)

The SaaStr Takeaway: Don’t accept linear growth deceleration as inevitable. Product innovation can reignite growth engines even at massive scale.

2. The Atlas Flywheel: How 72% Revenue Mix = Compound Advantages

The Numbers: Atlas (cloud) revenue grew 26% YoY and now represents 72% of total revenue.

The Flywheel Effect:

• Higher growth rates (26% vs 22% overall)
• Better unit economics (cloud margins typically superior)
• Customer stickiness (cloud platforms = higher switching costs)
• Expansion revenue (consumption-based model drives natural growth)

Why Most Companies Fail Here: They don’t get to 70%+ mix fast enough. MongoDB’s lesson: go ALL IN on your highest-growth, highest-margin product segment.

The SaaStr Takeaway: If you have a clear cloud/platform winner, accelerate the transition aggressively. 70%+ mix is where the magic happens.

3. The “Profitable Growth” Transition: From -40% to +16% Operating Margins

The Numbers: 16% non-GAAP operating margin in Q1 2026, up from negative margins just a few years ago.

How They Did It (The MongoDB Method):

• Disciplined hiring during the 2022-2023 downturn
• Revenue scale (easier to leverage fixed costs at $2B+ revenue)
• Product mix shift (Atlas has better unit economics)
• AI automation (reducing operational overhead)

The Critical Insight: MongoDB didn’t sacrifice growth for profitability. They achieved BOTH by:

1. Maintaining 20%+ growth rates
2. Improving operational efficiency
3. Focusing on high-margin products

The SaaStr Takeaway: The best SaaS companies don’t choose between growth and profitability. They engineer business models that deliver both.

4. Customer Acquisition at Scale: 2,600 Net Adds = Highest in 6 Years

The Numbers: 2,600 net new customers in Q1 2026, bringing total to 57,100+.

What’s Remarkable: This is their HIGHEST net customer additions in 6 years, despite being at massive scale. Most companies see customer acquisition slow down dramatically as they get bigger.

MongoDB’s Customer Acquisition Secrets:

• Self-serve motion for mid-market (efficient acquisition)
• Enterprise sales for large deals (higher ACVs)
• Developer-first approach (product-led growth at its finest)
• AI use case expansion (new buying centers)

The Pattern: Great SaaS companies don’t just rely on expansion revenue. They keep growing their customer base aggressively.

The SaaStr Takeaway: If you’re seeing customer acquisition slow down, you’re either: (a) not expanding your TAM enough, or (b) not building efficient enough acquisition motions.

5. The $800M Share Buyback Signal: Ultimate Confidence Indicator

The Numbers: MongoDB announced an additional $800M share repurchase authorization, bringing total to $1B.

Why This Matters: Share buybacks at high-growth SaaS companies send a powerful signal:

• Cash generation confidence ($105.9M free cash flow in Q1)
• Limited M&A pipeline (organic growth is working)
• Stock undervaluation belief (management thinks shares are cheap)
• Capital allocation maturity (beyond just “growth at all costs”)

The Broader Trend: We’re seeing more SaaS companies return cash to shareholders as they mature. This isn’t a sign of slowing growth – it’s a sign of capital allocation sophistication.

The SaaStr Takeaway: When you’re generating serious cash flow, thoughtful capital allocation becomes a competitive advantage.

The Bottom Line: MongoDB’s Playbook for $2B+ SaaS Success

MongoDB is showing us what “mature SaaS excellence” looks like:

• Growth: Still growing 20%+ at $2B+ scale
• Profitability: 16% operating margins and improving
• Efficiency: Record customer acquisition with strong unit economics
• Cash Generation: $105.9M free cash flow in one quarter
• Capital Allocation: Returning cash while investing in growth

The Meta-Lesson: The best SaaS companies don’t “grow up” and become boring. They become MORE impressive as they scale.

5 More Quick-Hit Learnings:

• Self-Serve Channel Explosion: Record 2,600 net customer adds (highest in 6+ years) driven by self-serve acquiring mid-market efficiently – May Petri’s promotion to CMO reflects this success
• Voyage AI Integration Speed: Released Voyage 3.5 embeddings just 4 months post-acquisition, reducing storage costs 80%+ and outperforming competitors – fast M&A integration execution
• Enterprise Penetration Strategy: 75% of Fortune 100 and 50% of Fortune 500 already customers – focus shifting to “expand in those accounts” vs new logo acquisition at top end
• Competitive Moat Widening: Dev’s take on Snowflake/Databricks buying Postgres companies: “Why does the world need a 15th or 16th Postgres derivative?” – MongoDB = Postgres + Elastic + Pinecone + Cohere in one platform
• Developer Productivity Focus: Atlas instances 80% provisioned via code (matching Neon’s stat), plus new docs in Mandarin/Portuguese/Korean/Japanese – global developer experience investment paying off

Source: MongoDB Q1 2026 Financial Results

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

New York State Common Retirement Fund grew its position in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 20.4% in the 1st quarter, according to the company in its most recent Form 13F filing with the Securities & Exchange Commission. The fund owned 113,134 shares of the company’s stock after purchasing an additional 19,174 shares during the period. New York State Common Retirement Fund owned about 0.14% of MongoDB worth $19,844,000 at the end of the most recent reporting period.

Other institutional investors have also recently modified their holdings of the company. Norges Bank bought a new position in MongoDB during the fourth quarter valued at approximately $189,584,000. Marshall Wace LLP bought a new position in shares of MongoDB during the 4th quarter valued at $110,356,000. D1 Capital Partners L.P. purchased a new position in MongoDB in the 4th quarter worth $76,129,000. Franklin Resources Inc. lifted its stake in MongoDB by 9.7% in the fourth quarter. Franklin Resources Inc. now owns 2,054,888 shares of the company’s stock worth $478,398,000 after purchasing an additional 181,962 shares during the last quarter. Finally, Pictet Asset Management Holding SA boosted its position in MongoDB by 69.1% during the fourth quarter. Pictet Asset Management Holding SA now owns 356,964 shares of the company’s stock valued at $83,105,000 after buying an additional 145,854 shares during the period. 89.29% of the stock is currently owned by institutional investors.

Insider Activity

In related news, Director Hope F. Cochran sold 1,174 shares of MongoDB stock in a transaction on Tuesday, June 17th. The stock was sold at an average price of $201.08, for a total value of $236,067.92. Following the completion of the sale, the director owned 21,096 shares of the company’s stock, valued at $4,241,983.68. The trade was a 5.27% decrease in their ownership of the stock. The sale was disclosed in a legal filing with the SEC, which is available at this link. Also, Director Dwight A. Merriman sold 820 shares of the stock in a transaction dated Wednesday, June 25th. The shares were sold at an average price of $210.84, for a total value of $172,888.80. Following the completion of the transaction, the director directly owned 1,106,186 shares in the company, valued at approximately $233,228,256.24. This represents a 0.07% decrease in their position. The disclosure for this sale can be found here. Insiders have sold a total of 32,746 shares of company stock valued at $7,500,196 in the last 90 days. 3.10% of the stock is currently owned by insiders.

MongoDB Stock Performance

Shares of NASDAQ:MDB traded up $0.98 during trading on Wednesday, reaching $209.64. 1,597,285 shares of the stock traded hands, compared to its average volume of 1,978,344. MongoDB, Inc. has a 52-week low of $140.78 and a 52-week high of $370.00. The stock has a market cap of $17.13 billion, a P/E ratio of -183.89 and a beta of 1.41. The stock has a 50-day moving average of $200.37 and a two-hundred day moving average of $213.39.

MongoDB (NASDAQ:MDB – Get Free Report) last posted its quarterly earnings results on Wednesday, June 4th. The company reported $1.00 earnings per share for the quarter, topping the consensus estimate of $0.65 by $0.35. The firm had revenue of $549.01 million during the quarter, compared to analysts’ expectations of $527.49 million. MongoDB had a negative return on equity of 3.16% and a negative net margin of 4.09%. The company’s revenue was up 21.8% on a year-over-year basis. During the same quarter in the previous year, the business earned $0.51 earnings per share. Sell-side analysts expect that MongoDB, Inc. will post -1.78 earnings per share for the current year.

Wall Street Analyst Weigh In

Several equities research analysts recently weighed in on MDB shares. Piper Sandler increased their target price on MongoDB from $200.00 to $275.00 and gave the company an “overweight” rating in a report on Thursday, June 5th. Wolfe Research initiated coverage on MongoDB in a research report on Wednesday, July 9th. They issued an “outperform” rating and a $280.00 price objective for the company. Cantor Fitzgerald raised their target price on shares of MongoDB from $252.00 to $271.00 and gave the stock an “overweight” rating in a report on Thursday, June 5th. Morgan Stanley decreased their target price on shares of MongoDB from $315.00 to $235.00 and set an “overweight” rating on the stock in a research note on Wednesday, April 16th. Finally, Macquarie reissued a “neutral” rating and set a $230.00 price target (up previously from $215.00) on shares of MongoDB in a research report on Friday, June 6th. Eight analysts have rated the stock with a hold rating, twenty-six have assigned a buy rating and one has given a strong buy rating to the stock. According to MarketBeat, the stock presently has a consensus rating of “Moderate Buy” and a consensus price target of $282.39.

View Our Latest Stock Report on MDB

MongoDB Company Profile

(Free Report)

MongoDB, Inc, together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

See Also

Before you consider MongoDB, you’ll want to hear this.

MarketBeat keeps track of Wall Street’s top-rated and best performing research analysts and the stocks they recommend to their clients on a daily basis. MarketBeat has identified the five stocks that top analysts are quietly whispering to their clients to buy now before the broader market catches on… and MongoDB wasn’t on the list.

While MongoDB currently has a Moderate Buy rating among analysts, top-rated analysts believe these five stocks are better buys.

View The Five Stocks Here

Looking to profit from the electric vehicle mega-trend? Enter your email address and we’ll send you our list of which EV stocks show the most long-term potential.

Get This Free Report

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Envestnet Asset Management Inc. lifted its holdings in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 44.6% during the 1st quarter, according to the company in its most recent filing with the SEC. The fund owned 127,425 shares of the company’s stock after purchasing an additional 39,311 shares during the period. Envestnet Asset Management Inc. owned about 0.16% of MongoDB worth $22,350,000 as of its most recent filing with the SEC.

Several other institutional investors and hedge funds also recently made changes to their positions in the business. Norges Bank bought a new position in shares of MongoDB during the 4th quarter valued at about $189,584,000. Marshall Wace LLP bought a new position in shares of MongoDB during the fourth quarter valued at approximately $110,356,000. D1 Capital Partners L.P. acquired a new stake in MongoDB in the fourth quarter valued at approximately $76,129,000. Franklin Resources Inc. raised its holdings in shares of MongoDB by 9.7% in the fourth quarter. Franklin Resources Inc. now owns 2,054,888 shares of the company’s stock worth $478,398,000 after buying an additional 181,962 shares during the last quarter. Finally, Pictet Asset Management Holding SA raised its holdings in shares of MongoDB by 69.1% during the fourth quarter. Pictet Asset Management Holding SA now owns 356,964 shares of the company’s stock worth $83,105,000 after purchasing an additional 145,854 shares during the last quarter. Institutional investors own 89.29% of the company’s stock.

MongoDB Trading Up 3.5%

Shares of MongoDB stock opened at $208.66 on Wednesday. The company has a market capitalization of $17.05 billion, a PE ratio of -183.04 and a beta of 1.41. MongoDB, Inc. has a 12 month low of $140.78 and a 12 month high of $370.00. The stock’s fifty day simple moving average is $200.37 and its 200 day simple moving average is $213.39.

MongoDB (NASDAQ:MDB – Get Free Report) last released its quarterly earnings results on Wednesday, June 4th. The company reported $1.00 earnings per share (EPS) for the quarter, beating the consensus estimate of $0.65 by $0.35. MongoDB had a negative return on equity of 3.16% and a negative net margin of 4.09%. The firm had revenue of $549.01 million for the quarter, compared to the consensus estimate of $527.49 million. During the same quarter last year, the business posted $0.51 EPS. The company’s revenue for the quarter was up 21.8% on a year-over-year basis. Analysts predict that MongoDB, Inc. will post -1.78 EPS for the current fiscal year.

Analyst Upgrades and Downgrades

A number of research firms recently weighed in on MDB. Guggenheim boosted their price target on shares of MongoDB from $235.00 to $260.00 and gave the stock a “buy” rating in a research report on Thursday, June 5th. Piper Sandler boosted their target price on shares of MongoDB from $200.00 to $275.00 and gave the company an “overweight” rating in a report on Thursday, June 5th. Cantor Fitzgerald boosted their target price on shares of MongoDB from $252.00 to $271.00 and gave the company an “overweight” rating in a report on Thursday, June 5th. Morgan Stanley decreased their target price on shares of MongoDB from $315.00 to $235.00 and set an “overweight” rating on the stock in a report on Wednesday, April 16th. Finally, Bank of America boosted their target price on shares of MongoDB from $215.00 to $275.00 and gave the company a “buy” rating in a report on Thursday, June 5th. Eight analysts have rated the stock with a hold rating, twenty-six have issued a buy rating and one has issued a strong buy rating to the company’s stock. According to MarketBeat, the stock has an average rating of “Moderate Buy” and a consensus price target of $282.39.

Read Our Latest Stock Analysis on MongoDB

Insider Buying and Selling

In other news, Director Dwight A. Merriman sold 2,000 shares of the business’s stock in a transaction that occurred on Thursday, June 5th. The stock was sold at an average price of $234.00, for a total transaction of $468,000.00. Following the completion of the sale, the director owned 1,107,006 shares in the company, valued at $259,039,404. The trade was a 0.18% decrease in their ownership of the stock. The sale was disclosed in a legal filing with the SEC, which is available at this hyperlink. Also, CEO Dev Ittycheria sold 25,005 shares of the business’s stock in a transaction that occurred on Thursday, June 5th. The stock was sold at an average price of $234.00, for a total value of $5,851,170.00. Following the sale, the chief executive officer owned 256,974 shares of the company’s stock, valued at approximately $60,131,916. This represents a 8.87% decrease in their position. The disclosure for this sale can be found here. Over the last 90 days, insiders sold 32,746 shares of company stock worth $7,500,196. Company insiders own 3.10% of the company’s stock.

About MongoDB

(Free Report)

MongoDB, Inc, together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

Featured Articles

Receive News & Ratings for MongoDB Daily – Enter your email address below to receive a concise daily summary of the latest news and analysts’ ratings for MongoDB and related companies with MarketBeat.com’s FREE daily email newsletter.

Article originally posted on mongodb google news. Visit mongodb google news