Uncategorized Archives - Page 2 of 436 - Mobile Monitoring Solutions

Uncategorized

MongoDB Target of Unusually Large Options Trading (NASDAQ:MDB) – MarketBeat

MMS • RSS

Posted on mongodb google news. Visit mongodb google news

MongoDB, Inc. (NASDAQ:MDB – Get Free Report) was the recipient of unusually large options trading on Wednesday. Traders purchased 36,130 call options on the stock. This is an increase of approximately 2,077% compared to the average daily volume of 1,660 call options.

MongoDB Stock Performance

Shares of MDB stock opened at $172.17 on Thursday. The stock has a 50 day moving average price of $188.41 and a 200 day moving average price of $246.79. MongoDB has a 52-week low of $140.78 and a 52-week high of $387.19. The firm has a market capitalization of $13.98 billion, a P/E ratio of -62.84 and a beta of 1.49.

MongoDB (NASDAQ:MDB – Get Free Report) last released its earnings results on Wednesday, March 5th. The company reported $0.19 earnings per share for the quarter, missing the consensus estimate of $0.64 by ($0.45). The business had revenue of $548.40 million for the quarter, compared to the consensus estimate of $519.65 million. MongoDB had a negative return on equity of 12.22% and a negative net margin of 10.46%. During the same quarter last year, the business posted $0.86 earnings per share. As a group, sell-side analysts forecast that MongoDB will post -1.78 EPS for the current year.

Insider Transactions at MongoDB

In related news, CEO Dev Ittycheria sold 18,512 shares of the company’s stock in a transaction that occurred on Wednesday, April 2nd. The stock was sold at an average price of $173.26, for a total value of $3,207,389.12. Following the transaction, the chief executive officer now directly owns 268,948 shares of the company’s stock, valued at approximately $46,597,930.48. This represents a 6.44 % decrease in their position. The transaction was disclosed in a legal filing with the SEC, which can be accessed through this hyperlink. Also, insider Cedric Pech sold 1,690 shares of MongoDB stock in a transaction on Wednesday, April 2nd. The stock was sold at an average price of $173.26, for a total value of $292,809.40. Following the completion of the sale, the insider now directly owns 57,634 shares of the company’s stock, valued at approximately $9,985,666.84. The trade was a 2.85 % decrease in their position. The disclosure for this sale can be found here. Insiders sold a total of 39,345 shares of company stock valued at $8,485,310 in the last quarter. 3.60% of the stock is owned by insiders.

Hedge Funds Weigh In On MongoDB

A number of institutional investors have recently modified their holdings of MDB. Cloud Capital Management LLC bought a new position in MongoDB in the first quarter worth approximately $25,000. Strategic Investment Solutions Inc. IL purchased a new stake in shares of MongoDB in the 4th quarter worth $29,000. Hilltop National Bank lifted its holdings in shares of MongoDB by 47.2% in the 4th quarter. Hilltop National Bank now owns 131 shares of the company’s stock worth $30,000 after buying an additional 42 shares during the period. NCP Inc. bought a new position in shares of MongoDB during the 4th quarter worth $35,000. Finally, Versant Capital Management Inc raised its holdings in shares of MongoDB by 1,100.0% in the fourth quarter. Versant Capital Management Inc now owns 180 shares of the company’s stock valued at $42,000 after acquiring an additional 165 shares in the last quarter. 89.29% of the stock is owned by hedge funds and other institutional investors.

Analyst Upgrades and Downgrades

MDB has been the topic of several research reports. Rosenblatt Securities restated a “buy” rating and issued a $350.00 target price on shares of MongoDB in a report on Tuesday, March 4th. Stifel Nicolaus dropped their price objective on shares of MongoDB from $340.00 to $275.00 and set a “buy” rating on the stock in a report on Friday, April 11th. Robert W. Baird reduced their target price on shares of MongoDB from $390.00 to $300.00 and set an “outperform” rating for the company in a report on Thursday, March 6th. Truist Financial cut their price objective on shares of MongoDB from $300.00 to $275.00 and set a “buy” rating for the company in a research report on Monday, March 31st. Finally, Loop Capital lowered their target price on MongoDB from $400.00 to $350.00 and set a “buy” rating on the stock in a research report on Monday, March 3rd. Eight analysts have rated the stock with a hold rating, twenty-four have assigned a buy rating and one has issued a strong buy rating to the company. According to data from MarketBeat.com, MongoDB presently has an average rating of “Moderate Buy” and a consensus target price of $294.78.

View Our Latest Report on MDB

MongoDB Company Profile

(Get 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.

Stock Traders Buy High Volume of MongoDB Put Options (NASDAQ:MDB) – MarketBeat

MMS • RSS

Posted on mongodb google news. Visit mongodb google news

MongoDB, Inc. (NASDAQ:MDB – Get Free Report) was the recipient of some unusual options trading on Wednesday. Stock traders purchased 23,831 put options on the company. This is an increase of approximately 2,157% compared to the average daily volume of 1,056 put options.

MongoDB Trading Down 1.4 %

Shares of MDB opened at $172.17 on Thursday. The stock has a market cap of $13.98 billion, a PE ratio of -62.84 and a beta of 1.49. MongoDB has a 1 year low of $140.78 and a 1 year high of $387.19. The stock has a 50 day simple moving average of $188.41 and a 200-day simple moving average of $246.79.

MongoDB (NASDAQ:MDB – Get Free Report) last announced its quarterly earnings results on Wednesday, March 5th. The company reported $0.19 earnings per share for the quarter, missing analysts’ consensus estimates of $0.64 by ($0.45). The company had revenue of $548.40 million during the quarter, compared to the consensus estimate of $519.65 million. MongoDB had a negative net margin of 10.46% and a negative return on equity of 12.22%. During the same quarter last year, the company earned $0.86 earnings per share. On average, sell-side analysts forecast that MongoDB will post -1.78 EPS for the current fiscal year.

Insider Activity at MongoDB

In other MongoDB news, CEO Dev Ittycheria sold 18,512 shares of the business’s stock in a transaction that occurred on Wednesday, April 2nd. The shares were sold at an average price of $173.26, for a total value of $3,207,389.12. Following the completion of the sale, the chief executive officer now directly owns 268,948 shares of the company’s stock, valued at $46,597,930.48. The trade was a 6.44 % decrease in their ownership of the stock. The transaction was disclosed in a legal filing with the SEC, which is available at this hyperlink. Also, CFO Srdjan Tanjga sold 525 shares of the firm’s stock in a transaction on Wednesday, April 2nd. The shares were sold at an average price of $173.26, for a total transaction of $90,961.50. Following the transaction, the chief financial officer now owns 6,406 shares in the company, valued at $1,109,903.56. This represents a 7.57 % decrease in their position. The disclosure for this sale can be found here. Over the last 90 days, insiders sold 39,345 shares of company stock valued at $8,485,310. Insiders own 3.60% of the company’s stock.

Institutional Investors Weigh In On MongoDB

Hedge funds have recently made changes to their positions in the company. Vanguard Group Inc. grew its stake in MongoDB by 0.3% during the fourth quarter. Vanguard Group Inc. now owns 7,328,745 shares of the company’s stock worth $1,706,205,000 after buying an additional 23,942 shares during the last quarter. Franklin Resources Inc. grew its position in MongoDB by 9.7% during the 4th quarter. Franklin Resources Inc. now owns 2,054,888 shares of the company’s stock worth $478,398,000 after acquiring an additional 181,962 shares during the last quarter. Geode Capital Management LLC increased its holdings in MongoDB by 1.8% during the 4th quarter. Geode Capital Management LLC now owns 1,252,142 shares of the company’s stock valued at $290,987,000 after purchasing an additional 22,106 shares in the last quarter. First Trust Advisors LP raised its position in MongoDB by 12.6% in the 4th quarter. First Trust Advisors LP now owns 854,906 shares of the company’s stock valued at $199,031,000 after purchasing an additional 95,893 shares during the last quarter. Finally, Norges Bank acquired a new position in MongoDB in the fourth quarter worth $189,584,000. Institutional investors and hedge funds own 89.29% of the company’s stock.

Analyst Upgrades and Downgrades

MDB has been the topic of a number of recent analyst reports. Truist Financial cut their price objective on MongoDB from $300.00 to $275.00 and set a “buy” rating on the stock in a research note on Monday, March 31st. Bank of America dropped their price target on shares of MongoDB from $420.00 to $286.00 and set a “buy” rating on the stock in a research report on Thursday, March 6th. Piper Sandler lowered their target price on shares of MongoDB from $280.00 to $200.00 and set an “overweight” rating on the stock in a research note on Wednesday, April 23rd. China Renaissance began coverage on shares of MongoDB in a research report on Tuesday, January 21st. They set a “buy” rating and a $351.00 target price for the company. Finally, Royal Bank of Canada lowered their price target on MongoDB from $400.00 to $320.00 and set an “outperform” rating on the stock in a research report on Thursday, March 6th. Eight analysts have rated the stock with a hold rating, twenty-four have given a buy rating and one has assigned a strong buy rating to the company. According to data from MarketBeat.com, MongoDB currently has a consensus rating of “Moderate Buy” and an average price target of $294.78.

Check Out Our Latest Stock Analysis on MDB

About MongoDB

(Get Free Report)

Storage news ticker – May 2 – Blocks and Files

MMS • RSS

Posted on mongodb google news. Visit mongodb google news

Cerabyte is participating in 2025 OCP EMEA Regional Summit, taking place April 29–30 in Dublin, Ireland. It will be putting its ceramic-on-glass storage to the test – by boiling it in salt water, and then baking it before fully recovering the data on it. See a video here.

…

Commvault has disclosed a flaw, tracked under CVE-2025-3928, being an unspecified security problem that authenticated attackers can exploit remotely to plant webshells on target servers. Commvault web servers are user-facing and API components of a backup system used by enterprises to protect and restore critical data. According to a Bleeping Computer report, the flaw is under active exploitation in the wild. CVE-2025-3928 was fixed in versions 11.36.46, 11.32.89, 11.28.141, and 11.20.217 for Windows and Linux platforms.

…

Dan Beer resigned from the StorMagic CEO slot, with Susan Odle replacing him there, to join CrashPlan as its CEO, and CrashPlan has just announced a unification of its data protection and cyber-resilience products in a combined platform. This provides a a Microsoft Azure-Centric cyber-resilience soffering for data protection and governance from a single SaaS platform.

CrashPlan is a data resiliency SaaS platform that solves ransomware recovery, device migration, legal hold, and disaster recovery customer challenges. CrashPlan protects data where each unique organization needs it to be stored – endpoints, servers, Microsoft 365, or Google Workspace – while allowing customers to unlock value in their data. CrashPlan is a trusted provider for over 50,000 organizations worldwide, including major enterprises and universities.

CrashPlan originally launched in 2007, and was acquired by Mill Point Capital in 2022. Mill Point Capital is a private equity firm focused on control investments in lower-middle market companies across the Business Services, Industrials and IT Services sectors throughout North America, with over $3 billion of cumulative capital commitments.

…

Data integration supplier Fivetran is acquiring reverse ETL company Census. It says the deal makes Fivetran the only fully managed platform that enables enterprises to move governed, automated and real-time data across their entire stack – from source systems to data platforms back into the business applications that drive decision-making. Founded in 2018 and headquartered in San Francisco, Census has grown to serve hundreds of customers across industries and currently employs over 200 people. The Census team will join Fivetran as part of the acquisition, and co-founder and CEO Boris Jabes will join to help lead the company’s data activation strategy moving forward

…

GigaIO composes CPUs, GPUs, and other accelerators with its FabreX memory fabric software. it’s partnering d-Matrix to integrate d-Matrix’s Corsair inference platform into GigaIO’s SuperNODE architecture to eliminate the complexity and performance bottlenecks traditionally associated with large-scale AI inference deployment. Highlights include processing capability of 30,000 tokens per second at just 2 milliseconds per token for models like Llama3 70B. Plus up to 10x faster interactive speed compared with GPU-based systems, 3x better performance at a similar total cost of ownership and 3x greater energy efficiency for more sustainable AI deployments.

…

Hammerspace has appointed Tom Whaley as VP Americas Sales. He joins from WEKA, where he was West Area Sales Director, with an extensive sales leadership history at VAST Data, mParticle and NetApp. Whaley will report to Hammerspace CRO Jeff Gianetti who also joined from WEKA in January.

…

HighPoint has introduced its Rocket 7604A, a 4x M.2 Gen5 x16 NVMe RAID AIC, designed for compact computing environments. It’s a half-length PCIe Gen5 x16 4-port M.2 NVMe RAID AIC with 167mm x 110mm dimensions and FH-HL form factor. The card has up to 32TB of storage capacity via a single PCIe slot, with four independent M.2 ports, delivering throughput of 64 GBps and 12 million IOPS. Learn more here.

…

CRN reports two Hitachi Vantara Pentaho BA Server vulnerabilities were logged by the U.S. Cybersecurity and Infrastructure Security Agency in March in CISA’s Known Exploited Vulnerabilities Catalog based on evidence of active exploitation.

…

SaaS backup and data recovery experts Keepit has been named a champion in the Canalys Managed BDR Leadership Matrix 2025 for backup and disaster recovery.

…

Lenovo has promoted Per Overgaard from ISO CTO EMEA ISG to General Manager for ISG EMEA, Overgaard held senior roles at IBM and HP before joining Lenovo in 2015 as part of the System X acquisition from IBM. He will oversee operations in a region that benefits from local manufacturing capabilities – most notably, Lenovo’s factory in Hungary.

…

MongoDB announced that Mike Berry will become the company’s new CFO effective May 27. Berry, the ex-CFO of NetApp, has 30-plus years of experience in the technology and software industry, serving as CFO for seven different companies prior to joining MongoDB, including McAfee, SolarWinds, and Informatica. In August 2024, Berry announced his plans to retire from NetApp once a successor was named (which happened on March 10, 2025) and then said the opportunity to join a company the caliber of MongoDB was “incredibly compelling.” The hire follows the abrupt resignation of prior MongoDB CFO Serge Tanjga.

…

Nvidia says it is bringing runtime cybersecurity to every AI factory with a new DOCA Argus software framework, part of its cybersecurity AI platform, and running on the BlueField DPU/SmartNIC. DOCA Argus operates on every node to detect and respond to attacks on AI workloads, integrating with enterprise security systems to deliver real-time threat insights.

…

RAID, Inc. has launched the DataEdge Transporter (“DET”) for high-capacity data transfers between edge locations. It uses FIPS-2 with TPM v2 media and has dual port 200GbE connectivity, over 350TB of flash storage per 2U rack and comes with a highly durable roll-away carrier to bring data from one location to the next. The out-of-the-box architecture delivers up to 8GB per second and is fully TAA compliant, making it ideal for the highest levels of data security and government missions.

…

Redis CEO Rowan Trollope blogs that MongoDB, Elastic and Redis all adopted SSPL to protect their business from cloud providers extracting value without reinvesting. But there was a downside, Trollope saying: “This achieved our goal—AWS and Google now maintain their own fork—but the change hurt our relationship with the Redis community. SSPL is not truly open source because the Open Source Initiative clarified it lacks the requisites to be an OSI-approved license.” So Redis is adding the OSI-approved AGPL as an additional licensing option for Redis, starting with Redis 8, which is now GA.

Redis 8 has support for vector sets, and integrates Redis Stack technologies, including JSON, Time Series, probabilistic data types, Redis Query Engine and more into core Redis 8 under AGPL. It provides over 30 performance improvements with up to 87 percent faster commands and 2x throughput. Trollope says it is: “Improving community engagement, particularly with client ecosystem contributions.”

…

Cloud-based real-time analytics company StarTree announced Model Context Protocol (MCP) support and vector embedding model hosting based on Amazon Bedrock. These capabilities enable StarTree to power agent-facing applications, real-time Retrieval-Augmented Generation (RAG), and conversational querying. StarTree also announced the general availability of Bring Your Own Kubernetes (BYOK), a new deployment option that gives organizations full control over StarTree’s high-performance analytics infrastructure within their own Kubernetes environments, whether in the cloud, on-premises, or in hybrid architectures.

…

Trino open source distributed SQL supplier Starburst has appointed Jitender Aswani as SVP Engineering. Aswani will report directly to Starburst CEO and Co-Founder, Justin Borgman, mad comes via stints at StarTree, Moveworks, Netflix, Facebook, SAP, CornerstoneResearch and HP.

…

A VAST Data blog says its unified, AI-infused DASE architecture is great for cyber-resilience with its multi-modal, learning defense system. A second blog says DASE-using AI agents can do the same for compliance.

…

Weebit Nano and tier-1 semiconductor foundry DB HiTek will show the first demonstration of DB HiTek’s Bipolar-CMOS-DMOS (BCD) silicon integrating Weebit’s Resistive Random-Access Memory (ReRAM) non-volatile memory (NVM) technology at PCIM 2025. PCIM is Europe’s largest power semiconductor exhibition, and will be held in Nuremberg, Germany, from May 6-8, 2025.

…

Western Digital said it would deliver 36TB-44TB HAMR disk drives by 2026 at an investor day. It will introduce HAMR technology around the 40TB capacity point, using its Optinand and UltraSMR technologies to get up that point with 11-platter drives, unlike Seagate which started transitioning to HAMR with 10-platter, 32TB drives. WD reckons it could reach 100TB capacity with its HAMR drivesby 2030.

…

Xconn Technologies demo’d dynamic memory allocation using CXL switch technology at CXL DevCon 2025. It used its Apollo CXL switch, the industry’s first to support both CXL 2.0 and PCIe 5.0 on a single chip. The switch enables terabyte-scale memory expansion with near-native latency and coherent memory access across CPUs, GPUs, and accelerators, including the 5th Gen AMD EPYC processors. Production samples of XConn Apollo XC50256 are available now.

…

The South China Morning Post reports a valuation of 161 billion yuan (US$22.1 billion) and losses incurred last year, have been revealed in a filing by a new investor in Yangtze Memory Technologies Co (YMTC), China’s leading flash memory chipmaker.

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

Uncategorized

Presentation: Slack’s Migration to a Cellular Architecture

MMS • Cooper Bethea

Article originally posted on InfoQ. Visit InfoQ

Transcript

Bethea: My name is Cooper Bethea. I’ve been an infrastructure engineer, an SRE, a production engineer. I worked at Slack and Google. I worked at a couple smaller places too. I worked at Foursquare, and Sift, formerly Sift Science. I’m a software engineer, but I’m bad at math. I like people. I’m better at people than I am at math. I ended up in this place where I’m doing a lot of work on site reliability and uptime, mostly because I was willing to hold a pager.

It turns out, in the end, this all adds up to me enjoying leading large infrastructure projects where the users don’t really notice anything, except at the end, everything works better. This talk is about one of these projects. I was an engineer at Slack, and I led a project to convert all of our user-facing production services from a monolithic to a cellular topology. How many of you use Slack at work? Clearly, this project needs some justification, and that’s what my VP thought too. I’m going to start by describing how we came to start this project.

Then I’ll give you an overview of how our production environment looked before, and then how it looked after, and these will look similar. You will wonder why this was so hard that I got to do a talk, because we didn’t even invent an algorithm or anything. This project was hard. I think projects like these are hard. We tried to do this at Slack once before, and it never really got off the ground. Part of what I’m going to talk about is how and why our rendition of this project actually succeeded.

One thing I would ask you to consider as you’re listening to this talk is these large migration projects often fail or run aground, even when you thought they would be simple, just changing one system to another system. We’re not even writing new software. A lot of the time, it’s just these reconfigurations of software. Why is this hard? This is some good old AI-generated slop that I made about a ship voyage, because a lot of these pictures are copyrighted. Similarly, we can ask, why did it used to be hard to sail a ship across the ocean? You know where you’re starting from, you know where you want to end up, but it was still hard. I think that big projects like these are similar, like these exploratory voyages that we used to do, where you know where you’re going, but you don’t know exactly how you’ll get there. I think that’s very confusing. It can be hard for organizations. Like all the best projects, this project was born from fear, anger, lost revenue, and a bad graph.

One day, we’re just slacking along, doing our projects, running the site or whatever, and this happens. This is a graph of TCP transmits split by availability zone in Amazon U.S.-east-1. For us, TCP transmits have always been a pretty clear sign that something is going wrong. Packets are getting dropped somewhere, whether it’s on one of the endpoint nodes, there’s a network and hardware in between, something is not good, and we need to take a look at that. If you look at the monitoring and do a little mental math, you can see that we have more of these dropped packets in one AZ than the others. You can see that the one sums to the same as the second two. We got the idea that this was about packets being lost traveling from that AZ into the other two AZs. We were like, that’s bad.

We basically called AWS, we did the thing where you filed your support ticket, and they were like, we were looking at it, and then we’re all sitting on Zoom. Then they found the network link and they fixed it, and all our errors went away. Then a few hours later, there was an automated system that put the link back in service, and it went down again. We called AWS again, and they processed the ticket, and they fixed it again. We were tired. We were just like, why do we have to go through this? Why do our users have to endure this? We built this distributed system, and it really ought to be able to deal with a single AZ being entirely unavailable. Why do we service errors? Why didn’t we just steer around the bad availability zone? It’s in the name, availability zone. You’re supposed to be able to build availability out of these things, multiples of them. We do a lot of trying to detect errors in distributed systems like, why didn’t that save us here either?

Slack’s Architecture

First, let’s take a look at the architecture of Slack. It’s a little different from what you’ll see at other sites, but not that weird. What we do is we have these edge regions where we terminate SSL close to users. We’ll get you a WebSocket out there. We’ll serve files, stuff like that that makes sense to push close to the users. Then the most important work on the site all actually happens inside U.S.-east-1. That’s where we retrieve channel histories.

If you post a message, that’s where the fanout starts. All that happens in one region, U.S.-east-1. What we do is we forward the traffic into this internal load balancing layer that you can see here that fronts each availability zone, and then these internal load balancers direct the traffic into a webapp, which is what you’re thinking, it’s based in Hack. It processes HTTP requests for users with the help of backend services and datastores. You would look at this and be like, we could just stop sending traffic to that AZ, and this would just work. We should just have done that when we had the outage. That didn’t work because this slide is a lie, because this is actually what everything looks like behind the webapp servers. You can see what’s going on here. This is spiritually descended from these three-tier architectures that we know. You’ve got a reverse proxy.

Then you’ve got an app server that terminates HTTP. Then you’ve got some databases behind it that it gets data from to answer these questions. We’ve just got this extra layer of reverse proxies because we’re crossing a regional boundary. We’ve got a whole bunch of different services on top of the database, including Memcache. There’s a Pub/Sub system that does fanout. There’s a search tree, stuff that is useful to the webapp in answering these queries. You’ll notice that most of these services are actually being accessed cross-AZ, because that was how we built them out, basically. We were counting on failover happening. We weren’t paying attention when we set up this part of the stack.

It turns out we got even more problems than that. Our main datastore is Vitess, which is a coordination layer, a sharding layer on top of MySQL in the end, and it’s strongly consistent. It needs a single write point for any given piece of data. You have to manage failover within the system. You can’t just stop sending Vitess traffic in one zone. If that zone contains the primary for a shard, you actually need to do an operation in Vitess to failover primariness, mastership of that shard to a different availability zone. We’ve got our work cut out for us at this point. We couldn’t pop the AZ out of frontend load balancing, but maybe we could do this automated thing I was talking about. Like just have the computers figure it out themselves and be like, that’s not really good anymore. We can just have the app service manager in our backends and fail away from the impacted AZ. This is a simplified waterfall. There’s a chunk of a waterfall graph between the webapp and its backends.

Once an API request from a user gets in there, there’s actually a lot of fanout. It’s not just these five RPCs, it’s maybe 100 RPCs. I’m like, wave our hands, like if you need to do 100 RPCs to your backends and you’re living with a 1% error rate, you’re probably not going to ever assemble a whole HTTP request, without a bunch of retries, things getting slow and messy. Then, conversely, once the app server is trying to handle things, the only reasonable response to like, I’m serving a lot of errors, I’m missing a lot of my backends, is for it to just lame duck itself to the load balancer and get taken out. This is viscerally unnerving to me, because we are forced to face this idea that if these webapp servers all have the same backend dependencies and they’re starting to lame duck themselves because one of these backends that they’re fanning in on is failing, we’d have a big possibility for cascading failure across the site.

Another consideration is like, in Memcache, you mostly shard your data via clients hashing over backend, use consistent hashing. Clients in the affected AZ had a different view of their backends in the Memcache ring, so we would get cache items duplicated in the Memcache ring. There’s some little consistency issues in there, and they can be found missing when they actually exist. That’s a recipe for database pressure, which again, fanning in, overloading the site in a bad way.

We thought about all this and we were like, it’s actually hard for the computers to do the right thing here. We want, perfectly, all the webapps in that one AZ to lame duck themselves and none of the webapps anywhere else to lame duck themselves. Then we got to do some stuff with Vitess, we’ll talk about later. It just felt bad. We were humans and we could see the graphs. We were sitting on the Zoom call being like, maybe we should drain this availability zone. If we could have smashed the button, we would have smashed the button, and we would have done it. We were also worried that if we remove traffic entirely from one AZ, it would maybe overload the other two AZs and send the site in cascading failure. We’re limping along at this point.

Originally, we’re serving like 1% errors. We are not in our SLO. It’s not as bad as it could be. We were afraid that we could send it into cascading failure and make it worse. We had some ideas, but we didn’t really trust it. It’s really scary to do things for the first time in an incident. What actually happened is we just sat on Zoom and talked about it for a while, and then AWS fixed it while we were talking about it. Then we felt bad. I felt bad enough that I wrote a post in Slack because that’s what we did there. It was called, we should be able to drain an AZ. Everybody was like, yes, we should. Then we’d made a plan.

Cellular Design

I’m going to start by talking about cells. In our implementation, a cell is an AZ. A cell is a set of services in an AZ. That set may be drained or removed from service as a unit. This is what we ended up looking like. Here’s the goals that we needed to satisfy. We took this backwards. We arrived at the cellular design by considering this actual use case that we had, which is, we wanted to be able to drain an AZ as much as possible.

Our goals are, remove as much traffic as possible from an AZ within five minutes. This is just table stakes when you’re in like four or five nines and higher territory, you need tools that work fast because you only get to have a little bit of downtime. Drains must not result in user visible errors. One of the things about being able to drain a data center in AZ is it’s a generic mitigation. As long as a failure is contained within a single AZ, you can just be like, something is weird in this AZ, I’m going to drain it. You can do that without understanding the root cause. It offers you a chance to make things better for your users while you’re still working on understanding what went wrong. If we add errors by draining, we’re probably not going to want to do that because it will make our SLOs worse. Drains and undrains must be incremental.

By the same token, what we want is we want to be able to pull an AZ, fix whatever we think broke inside that AZ, and then leak a little bit of traffic back in there, just like 1% or something, and be like, are we still getting errors? Did we fix the thing? It’s much better than just dumping all the traffic back in there. We wanted to be very incremental to a 1%-ish layer. Finally, the drain mechanism must not rely on the impacted AZ. Sometimes, especially when we have these big network outages, you’ll see some of the first things that we did when we were trying to make this work is we would SSH around the servers and make them lame duck themselves. We just did not want to be in a place where we were trying to do that on the end of a bad network link in a real big incident.

How Things Were Done, and Choices Made

Now I’m going to talk about the ways that we did it and back into how we choose to do those things. The first one, this is pretty straightforward and it’s the thing that you’re probably already thinking about, siloing. We have servers in one AZ and they just talk to upstream servers in that same AZ. It’s pretty simple, and for services that it works for, it works great. This is mostly a matter of configuration for services that are ok with this. We did some help in the service discovery layer and our internal service mesh to support this, but you don’t really need to do all that stuff.

Other services on the other end, difficulty, we have Vitess, where, as I mentioned, we have to internally manage the draining. Anything that’s strongly consistent in your architecture is probably going to need to have writes processed through a single primary point. You’ll have to do some failover. In our case, we’re actually able to do this faster than it seems in Vitess because each of these shards is independent. As long as there’s not too much pressure on the database overall, you can start flipping the shards in parallel and actually go quite quickly. We ended up building features into some autohealing machinery that we have for Vitess that would let us do this really quickly.

Then we started thinking like, what do we choose for each service and why? I’ve mentioned some things about state and strong consistency. It would be nice to have something a little more principled to think about here. Like I said, we like the siloing the best we can do it. Service centers don’t have to manage drains for themselves. They get to have three or four isolated instances of their service, so the blast radius of failures is better. In practice, they can’t all do that. Services that can do this and can’t do that, sort of break down by this idea of stateful or stateless. Like, is the service a system of record for some piece of data? If so, it will probably be harder to just silo.

Further than that, we can look at the CAP theorem a little bit to get an idea. We know the CAP theorem tells us that a system can be available during a network partition, or it can be consistent during a network partition, but not both. Actually, in practice, this ends up being a little more of a continuum. There are different pieces of storage software that satisfy this differently with different properties. When you look here, we’ve got the webapp, which is our canonical stateless thing. It’s just processing based on stuff it gets from datastores. Then we’ve got Vitess on the other end, and that’s strongly consistent.

In the middle, we actually have stuff like our Pub/Sub layer or the Memcache. It turned out that we were using Memcache as a strongly consistent datastore, which is the default thing that you do because you’re just always writing to one Memcache node and then reading out of that Memcache node again. This didn’t really work out great for us, but we found that there were many places in our application where we had trusted that we would have strongly consistent semantics. One of the things that we ended up doing for Memcache, and this is me trying to give you a little bit of flavor around the decision-making process, is we set up a series of per-cell Memcaches. Then we maintained a global Memcache layer, and we slowly, call site by call site, migrated from the old system to the new system.

Let’s look at one other thing here. We’ve got this other idea of services that need to be global, but they’re built on these strongly consistent datastores. For example, we used Consul for service discovery. Consul, underneath it all has a consensus database that is strongly consistent. A Consul cluster tends to fail as a unit and totally. What we used to do is we had many of these Consul clusters, they were striped across all the availability zones.

Eventually, we were able to bring down the number of Consul clusters in each availability zone into a high and low priority. Then we use our xDS Control Plane. xDS is the Envoy API for dynamic configuration. We were also able to use that for service discovery information, since that’s just a subset of what it’s already doing. We have this eventually consistent read layer where you see the Global xDS Control Plane over at the top, and it sits on top of these pre-AZ Consul clusters and assembles the information and presents it to them. By maintaining this as an eventually consistent service, if you have to run global services, I really recommend that they be eventually consistent as much as possible. It’s just the data model makes sharding and scaling much simpler. It’s a pretty safe choice for you. You can also see that we’ve brought down the number of Consul clusters. I’ll talk about that later. There’s a way in doing this project that we were able to do some things that we’ve been putting off, some housekeeping.

Finally, there’s the drain mechanism itself. We have traffic control via the Envoys and the xDS to get to the drains. As mentioned, the first implementation, we would use service to health check down. That’s why you see a duck emoji. We decided that that wasn’t incremental or nice enough for the data. There’s a very nice feature in the Envoy configuration called traffic weighting. We can just say, by default, everybody gets 33%. Then when we drain, we will set the cell to 0%. It just works.

Now I’ll back out. Here’s our original diagram. This is where we started. Again, here’s where we ended up. I’m going to flip back and forth a couple times. You can see we have less lines now. Things are nice and orderly. I’m glad that the slide is laid out this way. We’ve controlled the cross-AZ traffic in some pretty nice ways. We just have a few services that are talking cross-AZ now, and we’re being choosy about them. We can treat these services with more care, because we’re letting them break some cellular boundary, and there’s some potential for bad data poisoning, like for them to put load on other cells.

Fortunately, these are already our databases and our systems that are the system of record for data. We’re already being careful about them. Everybody who runs databases says it’s hard. I’ve always avoided it. This also gives us a model for bringing up a new availability zone if we want to, because we can just build one of these things out, build the data storage systems, start the replication underneath, and then build the other layers up from the bottom, and eventually enable them in load balancing. If we want to move around, do more or less AZs, stuff like that in the future, it becomes more like doing one at the end.

The Success Drivers

I did say we tried and failed to do this before. This looks pretty simple, and I’ve explained it to you in a nice way. Why did we succeed this time? This is the part of the talk where things get messy, and we’re going to talk about people’s feelings and why doing stuff is hard. The first time we talked about doing this, we were going to make these empty isolated cells and build all the infrastructure into them, and at some point, go lights on and cut over. Among other things, there were going to be solid network boundaries between these cells. There’s going to be a bunch of data repartitioning. It gave us a lot of nice properties. In the end, it was too hard to do. The reason for that is because we couldn’t stop working on features. Customers do not care that you’re doing this. None of your customers care that you are rebuilding your production environment, I promise.

At the same time, we’re talking about building this very beautiful system here. This is a lot different from the old system. The whole time we’re like building these, we’re maintaining two very separate environments and production topologies. This is a big drag on productivity because you have to make everything work twice and then keep it working. The environment that you’re not using is going to decay over time and stuff. Not everything is going to be covered perfectly by integration tests. Weird things will fail. God help your monitoring. There’s a lot of divergence that is happening when you’re working in this mode. The mental overhead is really high. We were like, we couldn’t even do this in a quarter. You can’t take a quarter off work for your whole infrastructure organization to do stuff. There’s no way we flip it out really quick. The resource cost is also an issue.

If we’re paying double for the site the whole time, we’re going to get broke. In the end, we abandoned this design, not because the end state was flawed, but because we couldn’t really find good answers to the concerns about how we actually develop and roll it out. The core property this solution is lacking is incrementality. We can’t really move smoothly back and forth from the old regime of things to the new regime. We can’t keep working on other stuff at the same time without doubling effort.

Conversely, we don’t realize any value from this project until we cut everything over to the new system. There’s a very real risk that it’ll get canceled along the way. We’ll start trying to cut over to the new systems and realize that we are worse off than before. Then we’ve just made a big mess and everybody is mad at us. None of these problems are really, again, entwined with the beginning or end states. In these large projects, it’s the messy middle where all the complexity and risk is lying. You have to respect the migration process. It’s the most important and the most fraught part of any big project like this.

At this point, we went to the literature, actually. This is called the slime mold deck, a lot of people do. This guy, Alex Komoroske at Google wrote it. You can see the URL here, https://komoroske.com/slime-mold/, but also if you just Google, slime mold deck, it’s the first thing. Then a bunch of Reddit stuff for slime and decks. It’s actually about how these coordination headwinds can slow progress on projects in large organizations. As Alex states the problem, is that coordination costs go up as the organizations grow larger. That’s what actually this is all about, coordination costs. Our original plan required us to tightly coordinate across every service at the company to build these empty cells all the way up before you turn them on. We can’t really set things up so that engineering teams can take bites out of the problem for themselves quarter over quarter.

Every team is going to support two separate environments until everybody is done. What do we do instead? We embrace this approach where we’re doing bottom-up development. When we went service by service and really figured out what made sense for that service, you remember there was that rubric with like AP and CP, I told you about. The people working on the core project team, we just sat down with each service and worked on developing a one-pager, like, maybe you can’t just be siloed or maybe you can’t just fail over now, but can we get to that place? What do we need to do to do that? Then also, one of our tactics is that we really embraced good enough. One service not being compliant with this does not risk the whole project. We can’t like not turn the thing on because one service got delayed a quarter. People have outages. Priorities change. We need to not coordinate so tightly. We need to make it so that things converge.

The concept laid out in the slime mold deck is this idea that instead of doing a moonshot, a straight shot for a very ambitious project, you should do a series of roofshots where you’re not necessarily going the most direct route, but you’re locking in value at each step of the way. Each service in my example here, that becomes compliant, locks in value for the project and reduces our execution risk. We don’t go straight to the goal, we use it site by. Another way to look at this is we’re willing to sacrifice some efficiency in return for a reduced risk of failure overall. We operated at Slack in this way where the infrastructure teams were in the same organization, but were largely independent. I think this is pretty common at large organizations now. I believe that most services operate at a local maximum of efficiency.

Some people show up and are like, “This service is terrible. That must be awful. You must’ve designed it in a dumb way”. I don’t think that’s true. All the people that you’re working with are actually smart just like you are. They have just been operating under different constraints. Services evolve over time. Every service owner in particular has a laundry list of technical debt that they want to clean up and they never have time to. That is because tech debt is the price of progress. It is not some engineering sin. Some of these things that service owners want to do and never get the time to do will make cellularizing things easier. In our big project, we can give these teams air cover to reduce some complexity before they add it back.

For example, in the service discovery system, returning to this example, we used to operate all these functionally sharded Consul clusters, and they spanned AZs. The idea here was that we would separate these internal Slack servers from stepping on each other’s Consul clusters. That wasn’t actually the greatest idea because it turns out, once again, customers don’t care. Any of these critical services being down basically meant that Slack was down for everybody. We just knew which service to point the finger at when we had these outages. In the spirit of reducing complexity, as part of doing the work, we just moved to these high and low SLO clusters, each within an AZ. Then we assembled the service discovery information over the top using the xDS layer that I talked about before. We were able to collapse all these functional clusters into high and lower priority clusters.

The high priority clusters aren’t better and we don’t run them better. We just expect more from the customers of the high priority clusters. If you’re a critical service, you need to be attached to a high priority cluster. Then you need to be careful about how you use that shared resource. Again, this is one of these things like selecting the datastores where we’re able to zero in on these extremely critical services and expect a little more from them. As it turns out, teams love this. Even if the team that you’re working with isn’t really sold on cellularization as a project, they almost certainly think that their team has a lot better work to do, and they’re right. They can get some value to themselves just from cleaning up the tech debt. You can see how this leads to a place where the teams have both the flexibility and enthusiasm to work on this larger product.

Project Cadence

I’m going to talk about the cadence that we used in this project. I started with this one-pager, which is, we should be able to drain an AZ. I circulated it to a bunch of engineers from different teams that I knew and trusted. The goal here is really to identify anything that just obviously won’t work. You don’t need to plan this project all the way to the end from the beginning. Most of the time, you’re looking for reasons to stop. You can bring this to institutional design review processes, just circulate it to people and listen to everybody’s opposition to why it won’t work. At this point, you haven’t really spent a lot of effort. We haven’t spent a lot of effort organizationally on making this project work. If it doesn’t work, that’s fine. We didn’t waste too much effort here. At the end of this phase, in return, you should have enough confidence that you can go to the engineering management, go through whatever processes you need and get agreement to run a pilot for a quarter or two. There’s a theme here where we’re gradually committing more as we gain confidence.

At that point, you want to start with several high-value services and engage deeply to make progress. It’s important that they are high value and critical services because those services are probably the most complex and because they will pay off faster in terms of like when we get them cellularized. There we go, a big chunk of value from doing that service. We also know the complexity of the problem is tractable, and we get some ideas about the common infrastructure that we’ll build to help.

At the end of this phase, we’ll attain organizational buy-in again through the management chain to expand all critical services. This is going to be the longest phase of the project. You can imagine there’s like a graph of engineers over time, and this is definitely the fattest part of the graph. Then we’ll start tailing off later. At the end of this phase, what we really want to do is all services have items in their roadmap or we’ve decided they’re just not worth doing. We start tracking our progress really heavily during this phase. One thing that we do is we regularly would do drains of the AZ to see how much we can get. Then, week over week, we can make a graph that’s like, we removed more bandwidth, and it goes up, hopefully. Then we can also build the infrastructure. I mentioned we can do some things to help people in the service mesh, but there’s also deployment tooling, job control. This is the part where your shared infrastructure tooling and systems will need to start changing to accommodate.

Finally, in the last phase of this project, we’re going to wind down, where we set things up, so like the happy path for new services is going to be siloed by AZ. You have to go outside some guardrails in the configuration to make a global service. We make sure that our long-term work for non-compliant services is tracked in roadmaps and OKRs. Then any work that doesn’t make the cut, we have incident review processes. As long as we’re tracking these things that we decided not to do, we can always bring them back up in response to a need.

When is Good Enough, Good Enough?

Now I’m going to go and talk about what I mean by doing things just good enough. At some point, the juice isn’t worth the squeeze. We had data warehousing systems at Slack that were basically just used by data analysts. Maybe there’s some batch processes that run, but user queries basically never touched those data warehouses. We don’t really care if they become cellular or not. That’s fine. If we decide it’s really important at some point, sure, but we’re here on behalf of the customers. It’s probably fine to stop before we get to those. Again, as with the rubric before, we want some structured way to think about this. Our two concerns are really, how do we figure out where to stop, and how do we keep what we’ve gained despite not doing literally everything in our environment? We figured out where to stop by working with each service to figure out the criticality of that service. chat.postMessage, for example, is the name of the API method that you use to post a message into Slack.

If chat.postMessage needs to touch your service before it can return, you are very critical. You’re really important for us to convert. Then, side by side, we want to have some idea about difficulty. That’s where the getting together with each service team and writing this one-pager about like, what it would mean, what we think the best solution for that team is, and how much effort it will take us to get there. You can use this to gauge difficulty. Then this tuple of criticality, importance, and difficulty. Criticality and difficulty is a good way that you can interface with engineering management about this project. You can be like, this is important and hard. This is important and easy. This is not important and easy. This is not important and hard, and do this Eisenhower decision matrix thing. We did a lot of these in phase one and two. Then when we got to phase three, which is the very wide phase, everyone was used to looking at and talking about these things. There wasn’t a lot of back and forth about whether we were doing this the right way or not.

Again, incrementality is most important. You should expect some of these services will need to take maybe a year, or more than a year to really get everything done because sometimes your most critical services are the most backlogged services, and the most difficult to maintain. We need to maintain an awareness of where the moon is as we roofshot along quarter to quarter. We made it so that each team’s engineering roadmap actually had compliance with this program as a goal. Quick sidebar is that, I believe that engineering roadmaps are just completely crucial for teams in infrastructure, in larger companies. If you just have a short document that says like, “This is what our service is like now. This is what we think our service will be like in a year, and here are some ways that we are getting there”. It’s just a very powerful tool to communicate both outside your organization into the rest of the engineering organization. It’s a good way for team members to understand the value and importance of their own work. I love a roadmap.

Finally, we measured our progress with weekly drains. If you’ll remember, we were worried about the capacity implications of it. We were like, every Friday for a while, around noon Pacific, we would drain the AZ and see how far we got. Then we watched the number go up and up over time. We’d do like 10%, and then we’d be like, can we do 20%? Then keep pulling traffic until we got scared. I think we only broke stuff one time. It was really good because it was a great signal for us to give to the company that we were getting something done. It’s meaningful. It’s the amount of bandwidth that’s left. It is a reasonable stand-in for user requests going through there. We were able to make it move. When it stopped moving, we could have conversations about that, and when we could expect it to move again.

Where Does That Leave Us?

This is where we actually ended up. Siloed services are drainable in 60 seconds via the load balancing layer. The Vitess automation reparents the nodes away from the fast AZ, as fast as the replication permits. We didn’t get all the critical services there 100%, but they’ve all got their roadmaps. One thing that you can use if you feel like things are getting deprioritized for too long is like, is it that important if they’re not having outages? Maybe it’s not. Conversely, if they have outages, maybe cellularizing would help. This is a really good thing to include in your incident review process. We’ve built into all our relevant infrastructure systems this default happy path, which is siloed per AZ configurations. We’re doing regular drains. At some point, we were like, we’re just doing these enough now that we don’t need to do them every Friday. Once you’re in the cycle, then you start having a good feeling about your capacity planning and you’re able to do it, and this is something that you can do if there’s an outage. Finally, we got a little bit of a savings because we reduced cross-AZ data transfer costs. That was nice.

Do We Actually Use This Thing?

The question that people always ask is like, do you really drain? Yes, we do. You get to use it more over time. You can use it for these single AZ AWS outages, but then you can also use it to help you do deploys. The same database that we power the frontend drains from, we just open the same one up to internal service mesh customers. Then they can roll forward, roll back their services. It actually opens up this new blue-greenish deploy method, where instead of just having like blue-green, you have like AZ 1, 2, 3, 4.

Then if you want to deploy some software, you just drain one of those AZs, pop the new software on it, undrain to 1%, 10%, 20%, whatever, and step it up that way. You can do that. It can give you a cleaner rollback experience than just popping binaries, like some people do. Siloing is helpful in other ways too. Sometimes you can have a poisonous deploy of a service, where the service itself is ok, but it’s causing another service to crash somehow. The siloing just helps naturally because of that. You can only endanger your upstream services in your own AZ. In general, we got to a place where if something looks wrong and it’s bounded by an AZ, generic mitigation. Like, let’s just try a drain and see if it gets better. Drains are fast. Drains are easy to undo. We don’t have to root cause our problems anymore.

Lessons Learned

Finally, what do we learn about running infrastructure projects in a decentralized environment? You really have to listen to people and you really have to move gradually and incrementally. You have to remember that every service is operating at a local maximum. The way things are is not because people are foolish, it’s because of the evolutionary pressures that shape the development of your system. Projects like this can actually provide potential energy to help these services escape from their local maximum to something better.

Questions and Answers

Brush: Have you had someone have an outage that this would have helped and they hadn’t completed their roadmap yet? Has that happened yet?

Bethea: Yes. That actually was very satisfying while we were in progress. People would be like, we had this outage, and we’d be like, siloing would help you, actually. Have you considered doing our program?

Participant 1: At my company, we do something very similar to this every week, where we’re draining, it’s not in AWS right now, but we often run into challenges convincing leaders that this is a smart thing to do because sometimes putting strain on the system will have some impact. Did you all have that and how did you all overcome it, or address it?

Bethea: Especially when you first start doing this, people will get anxious. You are removing capacity from a system. You can either do it like the inductive or the deductive way, where you either pencil it out and be like, we should be able to do this. Or you can do what we actually ended up doing where we would do these drains and walk them up slowly, and then like, if things got hot. Also, there is, I think, a compelling argument to be made that if you can’t do it when things are pretty normal, then you really shouldn’t be doing it when things are really bad.

Bethea: Did going to silos impact our continuous deployment? Tremendously, actually, because we ended up redoing the way that we did deploys entirely. We used to have a deployment system that did a lot of stuff, but in the end, it went from maybe 10% to 100%, spread across all AZs. We actually reworked it to fill up an AZ first and then spread across the other AZs on the idea that we could just simply revert that AZ by draining.

Participant 2: Then, as it came up, you would ship the traffic to a new AZ, 1%, and then bring the others up, or you would have old version and new version of this traffic at the same time?

Bethea: I think we were doing a little bit of a hybrid version just for historical reasons where we would roll that AZ forward by popping the binaries, by just flipping the binaries. If we needed to revert during the process, we would just pull traffic.

See more presentations with transcripts

Uncategorized

JAT Capital Mgmt LP Sells 72,745 Shares of MongoDB, Inc. (NASDAQ:MDB) – MarketBeat

MMS • RSS

Posted on mongodb google news. Visit mongodb google news

JAT Capital Mgmt LP lessened its stake in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 84.3% in the 4th quarter, according to the company in its most recent 13F filing with the SEC. The institutional investor owned 13,575 shares of the company’s stock after selling 72,745 shares during the quarter. MongoDB comprises approximately 0.5% of JAT Capital Mgmt LP’s holdings, making the stock its 27th largest position. JAT Capital Mgmt LP’s holdings in MongoDB were worth $3,160,000 as of its most recent SEC filing.

Several other large investors also recently made changes to their positions in MDB. Strategic Investment Solutions Inc. IL bought a new stake in shares of MongoDB in the fourth quarter valued at approximately $29,000. Hilltop National Bank increased its position in MongoDB by 47.2% during the fourth quarter. Hilltop National Bank now owns 131 shares of the company’s stock worth $30,000 after acquiring an additional 42 shares during the period. NCP Inc. bought a new position in MongoDB during the fourth quarter worth $35,000. Versant Capital Management Inc increased its position in MongoDB by 1,100.0% during the fourth quarter. Versant Capital Management Inc now owns 180 shares of the company’s stock worth $42,000 after acquiring an additional 165 shares during the period. Finally, Wilmington Savings Fund Society FSB bought a new position in MongoDB during the third quarter worth $44,000. Institutional investors own 89.29% of the company’s stock.

Analyst Ratings Changes

MDB has been the topic of a number of research reports. Daiwa Capital Markets initiated coverage on shares of MongoDB in a research report on Tuesday, April 1st. They set an “outperform” rating and a $202.00 target price on the stock. Scotiabank reaffirmed a “sector perform” rating and set a $160.00 target price (down previously from $240.00) on shares of MongoDB in a research report on Friday. Loop Capital dropped their target price on shares of MongoDB from $400.00 to $350.00 and set a “buy” rating on the stock in a research report on Monday, March 3rd. Truist Financial lowered their price target on shares of MongoDB from $300.00 to $275.00 and set a “buy” rating on the stock in a report on Monday, March 31st. Finally, Stifel Nicolaus dropped their price objective on shares of MongoDB from $340.00 to $275.00 and set a “buy” rating for the company in a research note on Friday, April 11th. Eight research analysts have rated the stock with a hold rating, twenty-four have issued a buy rating and one has given a strong buy rating to the company’s stock. Based on data from MarketBeat, the company currently has a consensus rating of “Moderate Buy” and a consensus price target of $294.78.

Get Our Latest Stock Analysis on MDB

Insider Activity at MongoDB

In related news, CEO Dev Ittycheria sold 18,512 shares of the business’s stock in a transaction on Wednesday, April 2nd. The shares were sold at an average price of $173.26, for a total value of $3,207,389.12. Following the sale, the chief executive officer now directly owns 268,948 shares of the company’s stock, valued at approximately $46,597,930.48. The trade was a 6.44 % decrease in their position. The transaction was disclosed in a legal filing with the SEC, which can be accessed through this hyperlink. Also, insider Cedric Pech sold 1,690 shares of the business’s stock in a transaction on Wednesday, April 2nd. The shares were sold at an average price of $173.26, for a total transaction of $292,809.40. Following the completion of the sale, the insider now directly owns 57,634 shares in the company, valued at $9,985,666.84. This represents a 2.85 % decrease in their ownership of the stock. The disclosure for this sale can be found here. Insiders have sold 39,345 shares of company stock worth $8,485,310 in the last ninety days. Company insiders own 3.60% of the company’s stock.

MongoDB Trading Up 0.1 %

Shares of NASDAQ MDB opened at $174.69 on Wednesday. The firm has a market capitalization of $14.18 billion, a PE ratio of -63.76 and a beta of 1.49. MongoDB, Inc. has a 1 year low of $140.78 and a 1 year high of $387.19. The firm’s 50-day moving average is $190.43 and its 200-day moving average is $247.31.

MongoDB (NASDAQ:MDB – Get Free Report) last issued its earnings results on Wednesday, March 5th. The company reported $0.19 earnings per share (EPS) for the quarter, missing the consensus estimate of $0.64 by ($0.45). The business had revenue of $548.40 million during the quarter, compared to the consensus estimate of $519.65 million. MongoDB had a negative net margin of 10.46% and a negative return on equity of 12.22%. During the same period last year, the business posted $0.86 EPS. As a group, equities research analysts anticipate that MongoDB, Inc. will post -1.78 earnings per share for the current fiscal year.

MongoDB Company Profile

(Free Report)

Google Unveils Ironwood TPU for AI Inference

MMS • Steef-Jan Wiggers

Article originally posted on InfoQ. Visit InfoQ

Google has unveiled its seventh-generation Tensor Processing Unit (TPU), Ironwood, at Google Cloud Next 25. Ironwood is Google’s most performant and scalable custom AI accelerator to date and the first TPU designed specifically for inference workloads.

Google emphasizes that Ironwood is designed to power what they call the “age of inference,” marking a shift from responsive AI models to proactive models that generate insights and interpretations. The company states that AI agents will use Ironwood to retrieve and generate data, delivering insights and answers.

A respondent in a Reddit thread on the announcement said:

Google has a huge advantage over OpenAI because it already has the infrastructure to do things like making its own chips. Currently, it looks like Google is running away with the game.

Ironwood scales up to 9,216 liquid-cooled chips, connected with Inter-Chip Interconnect (ICI) networking, and is a key component of Google Cloud’s AI Hypercomputer architecture. Developers can leverage Google’s own Pathways software stack to utilize the combined computing power of tens of thousands of Ironwood TPUs.

The company states, “Ironwood is our most powerful, capable, and energy-efficient TPU yet. And it’s purpose-built to power thinking, inferential AI models at scale.”

Furthermore, the company highlights that Ironwood is designed to manage the computation and communication demands of large language models (LLMs), mixture of experts (MoEs), and advanced reasoning tasks. Ironwood minimizes data movement and latency on-chip and uses a low-latency, high-bandwidth ICI network for coordinated communication at scale.

Ironwood will be available for Google Cloud customers in 256-chip and 9,216-chip configurations. The company claims that a 9,216-chip Ironwood pod delivers more than 24x the compute power of the El Capitan supercomputer, with 42.5 Exaflops compared to El Capitan’s 1.7 Exaflops per pod. Each Ironwood chip boasts a peak compute of 4,614 TFLOPS.

Ironwood also features an enhanced SparseCore, a specialized accelerator for processing ultra-large embeddings, expanding its applicability beyond traditional AI domains to finance and science.

Other key features of Ironwood include:

2x improvement in power efficiency compared to the previous generation, Trillium.
192 GB of high-bandwidth memory (HBM) per chip, 6x that of Trillium.
1.2 TBps bidirectional ICI bandwidth, 1.5x that of Trillium.
7.37 TB/s of HBM bandwidth per chip, 4.5x that of Trillium.

(Source: Google blog post)

Regarding the last feature, a respondent on another Reddit thread commented:

Tera? Terabytes? 7.4 Terabytes? And I’m over here praying that AMD gives us a Strix variant with at least 500GB of bandwidth in the next year or two…

While NVIDIA remains a dominant player in the AI accelerator market, a respondent in another Reddit thread commented:

I don’t think it will affect Nvidia much, but Google is going to be able to serve their AI at much lower cost than the competition because they are more vertically integrated, and that is pretty much already happening.

In addition, in yet another Reddit thread, a correspondent commented:

The specs are pretty absurd. Shame Google won’t sell these chips, a lot of large companies need their own hardware, but Google only offers cloud services with the hardware. Feels like this is the future, though, when somebody starts cranking out these kinds of chips for sale.

And finally, Davit tweeted:

Google just revealed Ironwood TPU v7 at Cloud Next, and nobody’s talking about the massive potential here: If Google wanted, they could spin out TPUs as a separate business and become NVIDIA’s biggest competitor overnight.

These chips are that good. The arms race in AI silicon is intensifying, but few recognize how powerful Google’s position actually is. While everyone focuses on NVIDIA’s dominance, Google has quietly built chip infrastructure that could reshape the entire AI hardware market if it decides to go all-in.

Google states that Ironwood provides increased computation power, memory capacity, ICI networking advancements, and reliability. These advancements, combined with improved power efficiency, will enable customers to handle demanding training and serving workloads with high performance and low latency. Google also notes that leading models like Gemini 2.5 and AlphaFold run on TPUs.

The announcement also highlighted that Google DeepMind has been using AI to aid in the design process for TPUs. An AI method called AlphaChip been used to accelerate and optimize chip design, resulting in what Google describes as “superhuman chip layouts” used in the last three generations of Google’s TPUs.

Earlier, Google reported that AlphaChip had also been used to design other chips across Alphabet, such as Google Axion Processors, and had been adopted by companies like MediaTek to accelerate their chip development. Google believes that AlphaChip has the potential to optimize every stage of the chip design cycle and transform chip design for custom hardware.

About the Author

Steef-Jan Wiggers

Show moreShow less

Uncategorized

Podcast: Achieving Sustainable Mental Peace in Software Engineering with Help from Generative AI

MMS • John Gesimondo

Article originally posted on InfoQ. Visit InfoQ

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I’m sitting down with John Gesimondo. John, welcome. Thanks for taking the time to talk to us.

John Gesimondo: Yes. Thank you. Glad to be here.

Shane Hastie: Now, John, you were recently a QCon speaker. But before we get into that, tell us a little bit, who’s John?

Introductions [01:09]

John Gesimondo: Sure. Yes. I’m John. I’ve been a software engineer for quite a while now, I guess about 15 years. My undergrad was actually in business. I’m a self-taught engineer. But with enough time and diligence, you can do anything. I’ve been working at Netflix for the last six years, doing various things, mostly internal tools, and this will be relevant later, but I have ADHD and definitely some traits of autism. I’m super keen on software in the tooling space, and then I really enjoy optimizing life, especially thinking about mental health and how that touches on technology.

Shane Hastie: Your talk, Achieving Sustainable Mental Peace at Work, with the twist, using Gen AI… What brought that about?

Using generative AI for mental peace [02:07]

John Gesimondo: Well, organic. I basically just started using generative AI for basically everything in my life. There’s people at work that made fun of me for this. It’s actually hilarious, but I, in the early days, tried to apply Gen AI to everything I could possibly think of just as a pure explore. When things are brand new, it’s nice to know what they’re capable of. I really pushed the limits, and I found quite a lot of sticky areas with a lot of value that were actually in this work adjacent/work support, I guess, space. Maybe you could call it the socio side of sociotechnical. There’s been a lot there that has really helped me out at work, so tried to turn it into a framework and give it as a talk.

Shane Hastie: Let’s dig in first there… You’ve been using that to support the socio side of the sociotechnical systems. Why is mental such a challenge for us in the software engineering space?

Challenges of mental health in software engineering [03:20]

John Gesimondo: Oh, man. Software is just really complicated, the way that it’s actually made. Then, it’s obviously also technically challenging. There’s a lot of needs being managed and a lot of communication and organization. Then, I find that there’s a temporal nature of everything that really messes with it.

If you can manage to get the usual corporate stuff, let’s say, compared to a non-engineering situation in a corporation, it’s already hard. There’s a lot of organizing. You have cross-functional difficulty aligning goals and all this type of stuff. But then, with software, you have this added element of the temporal nature of “why are things the way they are? Who knows actually how this software works? Why did this person make this decision? Oh, they don’t work here anymore”. That creates a whole other aspect of things that makes it impossible to really keep things structured and predictable and on time.

You’ve also got incidents that happen. You have support rotation. You have this need to focus. But then, at the same time, there’s so much work that’s going to interrupt you by the nature of how this whole thing works. Quite a lot of forces going on here and most of them don’t have good answers. That leaves you with difficulty.

Shane Hastie: You said you came up with a framework. What is the framework?

Overview of the Sustainable Mental Peace Framework [04:58]

John Gesimondo: The concept that we’re trying to get to is sustainable mental peace, which I call basically a steadfast calm while you’re in the middle of work chaos.

If we accept that work chaos is inevitable based on the reasons we just gave, then there’s not much you can do to control the environment permanently. Therefore, you have to take matters into your own hands to make sure that you can deal with living in that environment in a peaceful way. That’s where the framework comes in.

The framework is specifically limited to stuff where you can use generative AI since that was the topic of the talk. The way that I framed it is… starting from the most unstable, is basically having tools to recover quickly from emotional difficulty. Then, next up is getting unstuck when you’re stuck. Then, the next is to enhance your planning and communication skills because proper planning and proper proactive communication can save you so much of the interruptions I was just mentioning. Structure often, in this area, gives you a sense of calm. That’s very helpful.

Then, after that, now, we’re in a state that’s more stable. You’d want to try to add more time doing the things that you intrinsically enjoy and attempt to shortcut the things that aren’t really bringing you any personal value, which we now have some tools to do. Then, lastly, try to do some divergent thinking to keep things interesting, and to see opportunities, and to have some fun sometimes.

Shane Hastie: We maybe work through the different stages. It feels to me almost like a Maslow Hierarchy Pyramid. If we start at that base, recovering quickly from emotional difficulties, that just… The stereotypical engineer is considered not to have emotions. But of course, we’re all emotional beings and do respond. How do we recover quickly?

Stage 1: Recovering from emotional difficulty and getting unstuck [07:24]

John Gesimondo: Yes, definitely. I think I can group the first two, so recovering from emotions and overcoming stuck points. I think they’re very similar. They’re both often emotional in nature. When I say recover from emotions, I’m thinking a more acute situation, like some trigger big or small, or sitting in a room with someone that you really don’t like, or something… Things happen. It’s just… creates these unstable mental states. For being stuck, it’s a milder version, but it’s as practically important.

How do you do this? In either case, basically, we’re looking at a AI therapy/AI coach model. With the “recover from emotions”, I recommend using prompts that actually mention some therapy techniques, so using CBT technique or using IFS, which is Internal Family Systems, can sometimes help. Especially if the person using this already goes to therapy, this is extra helpful because it’s like having the tools that your therapist may have already gone over with you available to you at any time, and you don’t have to run the whole thing yourself. You’re still having that interaction which really helps open up.

For overcoming stuck points, it’s a blend. It’s like sometimes you need a coach, which AI… Again, similarly, you can just prompt, in a way, to ask, “Be my coach. Help me through this. Get me back to taking action”. But in other times, it can start the work for you. Sometimes you’re stuck because you have blank page syndrome, for instance. You don’t have to deal with that anymore. You can generate a crappy draft that you hate, but at least you can be the editor now, instead of a person staring at a blank screen. I think those two… You’re looking at using the AI as a coach/therapist.

Shane Hastie: Then, moving into the next level, the planning and communication, getting better at that.

Stage 2: Enhancing planning and communication with AI [09:53]

John Gesimondo: In this case, now you’re looking at, again, a mix. I guess, in this one, you’re looking at actually doing things in the standard way. I think that this one touches on the neurodivergence themes a lot because this is where, at least in my experience, as someone with ADHD, my thoughts are very scattered. Actually, getting them into a structure that other people understand is not a free exercise.

Now, with copilots and such, that exercise can be actually fairly close to free, I would say: dumping a bunch of bullet points and making sure that I covered everything, and asking for a review and to expand the set of points to a proposed audience, like, “If I were this type of person, what would I say? If you were that type of person, what would you say?” Agreeing on the content and then refactoring. Put it in programming terms, the whole thing into exactly the way that the target audience would expect to see it. You can even get that down to quite local. Giving an example and a prompt, in this case, is super helpful for structure, tone, language.

As much as I love creativity, as a neurodivergent person, when it comes to planning and communication, the less creative the end result is, the more buttoned up and structured and follows-what-people-expect it is, the less people will ask you questions and interrupt you later. They’re the reason for these things. At least in my experience, the way I’m using this is as a shim. I call it the neurodivergent planning shim. You’re just taking away the code-switching that I would have to do to write this myself and delegating that work to the AI.

Shane Hastie: But it starts, of course, with your knowledge, what you’re providing it.

John Gesimondo: Yes, exactly. But that’s the fun part, at least for me. The back and forth in that middle process, when it’s about agreeing, “Is this the right content?” is really fun. Asking different personas… “What would this person say? Would that person say?” It’s a lot more efficient than actually asking those people, which, of course, we’ll do anyway later. But it’s a nice creative brainstorming at the beginning, and then just speed run me through the structuring part because my brain structure… not a natural fit, I will say.

Stage 3: Maximizing flow and enjoyment in Engineering Work [12:42]

For the add time in flow bit, this is all about… Each of us have different parts of engineering that we like to do the most. Even when you look within what I’ll call, I guess, the core loop of engineering, of actually writing code and testing it, documenting it, and getting feedback, and all of this stuff, even within that process, there’s a lot of preferences.

Even within writing the code, there are preferences. Some people like to do more theoretical stuff. Other people like to do the structuring and architecture and system design. I think that with the flow aspect here, what you’re hoping to do is spend more time on the parts you really like and less time on the other parts, and especially don’t get interrupted.

Previously, before AI was around, we all had to go to Stack Overflow and read through all kinds of different correct and incorrect answers for our problems. When you have to do that in the middle of a working session, it takes you out of the flow of everything.

Now, with copilots, we often get that information at the snap of a finger. That’s already helpful. But on top of that, I recommend tuning your overall time spent coding to be tuned towards the areas that you really deeply enjoy/that feel immersive for you and do that using any latest frontier tooling that you can find. The cool thing is that this is currently where the frontier moves the fastest, is in the copilot space. This one’s super fun to keep up to date on.

Shane Hastie: And then divergent thinking.

Stage 4: Enabling divergent thinking and creativity [14:35]

John Gesimondo: Yes. Divergent thinking is really interesting. I think this is a strength of neurodivergent people. I mean, there’s a reason why “divergent” is in the name. But, in a sense, it’s interesting because this whole framework is helping neurodivergent people and others. But for neurodivergent people, it helps them be a little more neurotypical for less cost. But in this case, this is the flip. This is like, “Help neurotypicals be more neurodivergent”.

It’s funny. My story is I’m looking for a place to live. I was considering different suburbs or, back to San Francisco, in the city. I just was stuck in… There’s trade-offs everywhere, and nothing’s capturing my attention. Sometimes when I’m in this situation, including at work, the answer is zoom out and get a little more divergent with the thinking. In this case, I asked ChatGPT for some ideas of… I asked it for some housing ideas. It gave me a normal list, and then I asked it, “Get a little more divergent with this list”. It came up with some really funny stuff.

One of them is the tethered air home. This is a living pod suspended from cables between skyscrapers, or cliffs, or large trees. Nice hammock-like structure; could be retractable, and can retract the ground level when needed. Not bad. There’s one that was really funny, which was a distributed home network, so instead of one location, your home is spread across multiple cities. But its cloud-connected lockers store your essentials, minimizing the need for luggage. I don’t think that’s how the cloud works. I don’t think that’s how physical systems work but sounds good.

Anyway, it really got me very unstuck. Now, my mind is open to… I don’t know how to explain it. That’s what happens when you do creative thinking. It just got that problem a little bit shaken up into some new directions. You can do that at work. I think especially when you look at career, or you look at people being technical leaders, you want to spend some time thinking about what could be. Sometimes, these crazy ideas turn into… They spark some actual practical ideas. It’s a fun process.

Shane Hastie: As a neurodivergent person, what has your journey been and how has the environment supported or inhibited you?

Personal journey with neurodivergence [17:40]

John Gesimondo: Well, I didn’t know I was neurodivergent until during COVID. There’s, I guess, two eras of this journey: unaware and the aware stage. I think the only time that being unaware was blissful was certain parts of school. I actually am a very, very curious person so whenever I was interested in the topic that was in that class, I did quite well. It was miserable when I wasn’t interested, but that didn’t happen that often, luckily for me. That was I will call the mostly blissful unaware period.

Where it was no longer blissful is when I started working. I think the further I’ve gone in my career, the more difficult it’s been, to be honest. As a junior who’s just expected to learn all the time, it’s school-like. It’s somewhat structured, depending on the environment. My environment was very structured, so that was great.

During mid-career, there’s a lot of learning to be done still, and a little bit more confidence, I think, in your abilities. You start to get to know your strengths, something that helps. There’s this linearish feeling/sense of learning. It’s clear that you’re getting smarter and better at this job, even if you just look at a maybe two-week basis. Even within a sprint, you’re like, “Oh, wow. That was hard. Now, I could do it again much faster”. It’s great.

Then I think it gets a little difficult after that. As a senior, it’s like the structure lines start to blur. I think that’s especially true at Netflix, but I’m sure it’s true of many places. But the structure starts to decrease, and, as you get even further past that, you’re expected to add some structure for the less tenured folks.

This is where I think the burden of planning and communicating and structuring things in ways that other people can understand and being able to manage… I don’t have an answer for this one, but being able to manage the worker… The maker schedule and the manager schedule getting mixed in your calendar is brutal when you have ADHD.

I think this is where the rigor of my systems has had to increase a lot lately because of pursuing being a technical leader. I mean, I think, for a lot of people… They just wouldn’t. But I think, in good and bad ways, my achiever side is stronger than my neurodivergence side is suffering. That means build the tools, learn the processes, add the rigor to the systems, and rely on AI so that I can have my sustainable mental peace and be able to achieve what I’m looking to achieve.

Shane Hastie: You said you got a formal recognition during COVID. What difference has that made for you?

The impact of formal neurodivergence recognition [21:03]

John Gesimondo: Oh. Yes. It helps and it hurts. I know there’s a lot of mixed feelings about finding out that you’re neurodivergent later in life. But I think, in a practical way, for me, it’s mostly been beneficial because you really have to understand that you experience things differently than the people around you to get to some point that you can do something about it.

If you don’t know that, then it feels like the world is gaslighting you all the time. Someone proposes a system, like, “Oh, just use a task list to organize your tasks”, and that system doesn’t quite work for you… Well, if you don’t know that you have ADHD, then it just makes you feel like, “Oh, something’s wrong with me, or I’m lazy, or I didn’t try hard enough”.

But if you do know you have ADHD, then you know that you should check… “Is this an ADHD problem, or is it a me problem?” You’ll find out, in this example, that it’s an ADHD problem. You just find an alternative, or you give yourself extra care and patience on the journey of trying to figure out how that works usually to find a workaround, or find support tends to work better. Definitely need patience either way.

I often see this analogy with glasses. It’s like if you don’t know that your vision is bad, and then someone’s talking to you about something that’s a little too far away, and you can’t see it, you don’t have anything to work with there. It’s a crazy feeling, like, “What are they talking about? Should I say I don’t understand what they’re talking about? Because they sound pretty confident about it. Everyone else knows what they’re talking about”. Then, it’s like, “Okay, now I wear glasses. Okay, great. Well, now I know that if I’m not wearing my glasses, then that’s the problem. I can’t see the thing because I don’t have my glasses on”.

It just gives you this sense of certainty, even though that doesn’t fix the problem, but it does make you feel better about it. You understand the problem. Then, you can start the road, I think, from there, of looking for solutions. I shouldn’t even say solutions. I think that’s a little unfair. There’s no solution per se, and there’s no… We don’t have to go fully down that road, but no need to solve the problem. But you do need to adapt if you want to work with a majority neurotypical people at work, which is usually the case.

Shane Hastie: Thank you for that. Good insights there. If we swing back around to flow, you mentioned vibe coding when we were chatting earlier. What’s it like, and how do you get into that? In the swing of that today?

Vibe coding and the future of AI in development [24:02]

John Gesimondo: Yes. Vibe coding is so fun, sometimes. Vibe coding, we’ll say, is… For those that are not familiar, I think most engineers know about copilots, like GitHub Copilot, for instance, been around for a while. But the latest frontier of this is to have an agent-based copilot, so you’re giving it one instruction.

It can go do an entire loop of work of many different back-and-forth prompts, and you can either approve each step, “Oh, I want to write to this file”, accept, “I want to write a test now”, accept, or you can just click the auto approve, and you can just sit back and watch and hope for the best. This is what we call vibe coding in the AI developer community. It’s a fun time.

For those listening that haven’t tried it, even managers, please try it because it is probably one of the most exciting yet jarring experiences I’ve had in a while, and I hear that from others as well. The jarring part is just… It’s the closest you get to that, “Are we still going to be having jobs in the next year?” But it’s just… I don’t know. It’s a mind-blowing experience.

It really flips everything that you think you know about what’s difficult, what’s easy, how I’m going to do my work from now on. When should I use this? What is it good at? But let me tell you, on the other side of it, it’s so hard to abstract any actual lessons from these experiences. What is it good at? You just try, and you find out. You’re either really delighted, or you’re basically trying to pair with a under-educated intern. One of those two, and you don’t know until you try.

Shane Hastie: Lean into the unknown and experience the flow.

John Gesimondo: Totally, totally. I see a lot of people… I guess we could combine this with divergent thinking as well because that allows you… If you’re coming up with what you think are crazy ideas, and they’re in the software space, it is easier than ever to make a prototype through vibe coding, especially that, because I think the big open question is, “What kind of code quality are we making for the maintainers of all this stuff?” But if you want to just play around and make a inspirational prototype of something, it’s never been easier. Just open up your favorite vibe coding copilot and pray.

Shane Hastie: The tester in me shutters.

John Gesimondo: Absolutely. Absolutely.

Shane Hastie: John, some great insights here, and some really interesting stuff. If people do want to continue the conversation, where can they find you?

John Gesimondo: I think LinkedIn would probably be best. My username on there is jmondo. I’m occasionally active on Twitter as well, or X, and that’s also @jmondo. I’d go with that.

Shane Hastie: Thank you so much.

John Gesimondo: Thank you.

Mentioned:

About the Author

John Gesimondo

Show moreShow less

.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Uncategorized

MongoDB Sees Unusually Large Options Volume (NASDAQ:MDB) – Defense World

MMS • RSS

Posted on mongodb google news. Visit mongodb google news

MongoDB, Inc. (NASDAQ:MDB – Get Free Report) was the target of some unusual options trading activity on Wednesday. Stock traders bought 23,831 put options on the company. This represents an increase of approximately 2,157% compared to the typical volume of 1,056 put options.

MongoDB Price Performance

Shares of NASDAQ:MDB opened at $172.19 on Friday. MongoDB has a 1-year low of $140.78 and a 1-year high of $380.94. The firm has a fifty day moving average price of $186.51 and a 200 day moving average price of $245.99. The stock has a market cap of $13.98 billion, a P/E ratio of -62.84 and a beta of 1.49.

MongoDB (NASDAQ:MDB – Get Free Report) last announced its quarterly earnings results on Wednesday, March 5th. The company reported $0.19 EPS for the quarter, missing the consensus estimate of $0.64 by ($0.45). MongoDB had a negative return on equity of 12.22% and a negative net margin of 10.46%. The firm had revenue of $548.40 million for the quarter, compared to analysts’ expectations of $519.65 million. During the same period last year, the firm earned $0.86 EPS. Sell-side analysts expect that MongoDB will post -1.78 EPS for the current fiscal year.

Wall Street Analysts Forecast Growth

<!—->

MDB has been the topic of several recent research reports. Bank of America cut their price objective on MongoDB from $420.00 to $286.00 and set a “buy” rating on the stock in a report on Thursday, March 6th. Rosenblatt Securities reaffirmed a “buy” rating and set a $350.00 price objective on shares of MongoDB in a research report on Tuesday, March 4th. Scotiabank reissued a “sector perform” rating and issued a $160.00 price objective (down previously from $240.00) on shares of MongoDB in a research note on Friday, April 25th. Piper Sandler lowered their price objective on MongoDB from $280.00 to $200.00 and set an “overweight” rating for the company in a research note on Wednesday, April 23rd. Finally, China Renaissance started coverage on shares of MongoDB in a research report on Tuesday, January 21st. They set a “buy” rating and a $351.00 target price on the stock. Eight investment analysts have rated the stock with a hold rating, twenty-four have assigned a buy rating and one has issued a strong buy rating to the company’s stock. Based on data from MarketBeat.com, the company currently has an average rating of “Moderate Buy” and a consensus price target of $294.78.

Read Our Latest Analysis on MongoDB

Insider Activity at MongoDB

In related news, CFO Srdjan Tanjga sold 525 shares of the business’s stock in a transaction on Wednesday, April 2nd. The stock was sold at an average price of $173.26, for a total value of $90,961.50. Following the completion of the sale, the chief financial officer now directly owns 6,406 shares in the company, valued at $1,109,903.56. The trade was a 7.57 % decrease in their position. The transaction was disclosed in a document filed with the SEC, which is available through the SEC website. Also, CEO Dev Ittycheria sold 18,512 shares of MongoDB stock in a transaction dated Wednesday, April 2nd. The stock was sold at an average price of $173.26, for a total transaction of $3,207,389.12. Following the completion of the sale, the chief executive officer now owns 268,948 shares of the company’s stock, valued at $46,597,930.48. This trade represents a 6.44 % decrease in their position. The disclosure for this sale can be found here. Insiders sold a total of 39,345 shares of company stock worth $8,485,310 in the last quarter. Corporate insiders own 3.60% of the company’s stock.

Institutional Investors Weigh In On MongoDB

Several hedge funds have recently modified their holdings of the stock. Strategic Investment Solutions Inc. IL purchased a new position in shares of MongoDB in the 4th quarter valued at $29,000. Hilltop National Bank lifted its holdings in shares of MongoDB by 47.2% in the 4th quarter. Hilltop National Bank now owns 131 shares of the company’s stock worth $30,000 after purchasing an additional 42 shares during the last quarter. Cloud Capital Management LLC bought a new stake in shares of MongoDB during the first quarter valued at approximately $25,000. NCP Inc. bought a new position in MongoDB in the 4th quarter valued at about $35,000. Finally, Wilmington Savings Fund Society FSB acquired a new stake in MongoDB in the third quarter worth approximately $44,000. 89.29% of the stock is owned by institutional investors and hedge funds.

About MongoDB

(Get Free Report)

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

Uncategorized

MongoDB, Inc. (NASDAQ:MDB) Given Consensus Recommendation of “Moderate Buy” by Analysts

MMS • RSS

Posted on mongodb google news. Visit mongodb google news

Shares of MongoDB, Inc. (NASDAQ:MDB – Get Free Report) have been given an average recommendation of “Moderate Buy” by the thirty-three research firms that are currently covering the company, Marketbeat Ratings reports. Eight equities research analysts have rated the stock with a hold recommendation, twenty-four have given a buy recommendation and one has issued a strong buy recommendation on the company. The average twelve-month target price among analysts that have updated their coverage on the stock in the last year is $294.78.

A number of research analysts have weighed in on the company. Rosenblatt Securities reiterated a “buy” rating and set a $350.00 target price on shares of MongoDB in a report on Tuesday, March 4th. Truist Financial decreased their price objective on MongoDB from $300.00 to $275.00 and set a “buy” rating for the company in a report on Monday, March 31st. Monness Crespi & Hardt upgraded shares of MongoDB from a “sell” rating to a “neutral” rating in a report on Monday, March 3rd. Scotiabank reiterated a “sector perform” rating and issued a $160.00 price target (down from $240.00) on shares of MongoDB in a research note on Friday. Finally, KeyCorp lowered shares of MongoDB from a “strong-buy” rating to a “hold” rating in a research note on Wednesday, March 5th.

Check Out Our Latest Report on MDB

Insider Buying and Selling

In other news, Director Dwight A. Merriman sold 3,000 shares of the business’s stock in a transaction on Monday, February 3rd. The shares were sold at an average price of $266.00, for a total transaction of $798,000.00. Following the completion of the sale, the director now owns 1,113,006 shares of the company’s stock, valued at $296,059,596. The trade was a 0.27 % decrease in their position. The sale was disclosed in a legal filing with the SEC, which is available at this link. Also, CAO Thomas Bull sold 301 shares of the firm’s stock in a transaction on Wednesday, April 2nd. The stock was sold at an average price of $173.25, for a total value of $52,148.25. Following the completion of the transaction, the chief accounting officer now directly owns 14,598 shares in the company, valued at approximately $2,529,103.50. This represents a 2.02 % decrease in their ownership of the stock. The disclosure for this sale can be found here. Insiders sold 39,345 shares of company stock valued at $8,485,310 over the last 90 days. Company insiders own 3.60% of the company’s stock.

Institutional Trading of MongoDB

Hedge funds and other institutional investors have recently bought and sold shares of the stock. Cloud Capital Management LLC bought a new stake in MongoDB during the first quarter valued at about $25,000. Strategic Investment Solutions Inc. IL purchased a new stake in shares of MongoDB during the fourth quarter worth about $29,000. Hilltop National Bank raised its stake in MongoDB by 47.2% during the 4th quarter. Hilltop National Bank now owns 131 shares of the company’s stock valued at $30,000 after purchasing an additional 42 shares during the period. NCP Inc. purchased a new position in MongoDB in the 4th quarter worth approximately $35,000. Finally, Versant Capital Management Inc boosted its stake in MongoDB by 1,100.0% in the 4th quarter. Versant Capital Management Inc now owns 180 shares of the company’s stock worth $42,000 after purchasing an additional 165 shares during the period. Hedge funds and other institutional investors own 89.29% of the company’s stock.

MongoDB Price Performance

NASDAQ MDB opened at $174.69 on Wednesday. The business’s 50-day moving average is $190.43 and its 200 day moving average is $247.31. The stock has a market capitalization of $14.18 billion, a PE ratio of -63.76 and a beta of 1.49. MongoDB has a 1 year low of $140.78 and a 1 year high of $387.19.

MongoDB (NASDAQ:MDB – Get Free Report) last issued its quarterly earnings data on Wednesday, March 5th. The company reported $0.19 earnings per share for the quarter, missing analysts’ consensus estimates of $0.64 by ($0.45). MongoDB had a negative return on equity of 12.22% and a negative net margin of 10.46%. The business had revenue of $548.40 million during the quarter, compared to the consensus estimate of $519.65 million. During the same quarter in the prior year, the business posted $0.86 earnings per share. As a group, equities research analysts anticipate that MongoDB will post -1.78 earnings per share for the current year.

MongoDB Company Profile

(Get Free Report

MongoDB Target of Unusually High Options Trading (NASDAQ:MDB) – Defense World

MMS • RSS

Posted on mongodb google news. Visit mongodb google news

MongoDB, Inc. (NASDAQ:MDB – Get Free Report) saw unusually large options trading on Wednesday. Stock investors bought 36,130 call options on the stock. This is an increase of approximately 2,077% compared to the average daily volume of 1,660 call options.

Insider Transactions at MongoDB

In other news, CAO Thomas Bull sold 301 shares of the firm’s stock in a transaction that occurred on Wednesday, April 2nd. The shares were sold at an average price of $173.25, for a total value of $52,148.25. Following the transaction, the chief accounting officer now owns 14,598 shares in the company, valued at approximately $2,529,103.50. This trade represents a 2.02 % decrease in their ownership of the stock. The sale was disclosed in a document filed with the Securities & Exchange Commission, which is accessible through this hyperlink. Also, Director Dwight A. Merriman sold 3,000 shares of the stock in a transaction on Monday, February 3rd. The shares were sold at an average price of $266.00, for a total transaction of $798,000.00. Following the sale, the director now directly owns 1,113,006 shares of the company’s stock, valued at $296,059,596. The trade was a 0.27 % decrease in their position. The disclosure for this sale can be found here. Over the last 90 days, insiders sold 39,345 shares of company stock valued at $8,485,310. 3.60% of the stock is owned by corporate insiders.

Institutional Investors Weigh In On MongoDB

A number of institutional investors have recently bought and sold shares of MDB. Cloud Capital Management LLC purchased a new stake in MongoDB in the 1st quarter worth $25,000. Strategic Investment Solutions Inc. IL purchased a new stake in MongoDB in the 4th quarter worth $29,000. Hilltop National Bank increased its stake in MongoDB by 47.2% in the 4th quarter. Hilltop National Bank now owns 131 shares of the company’s stock worth $30,000 after buying an additional 42 shares in the last quarter. NCP Inc. purchased a new position in shares of MongoDB during the fourth quarter valued at about $35,000. Finally, Versant Capital Management Inc grew its position in shares of MongoDB by 1,100.0% during the fourth quarter. Versant Capital Management Inc now owns 180 shares of the company’s stock valued at $42,000 after purchasing an additional 165 shares in the last quarter. Hedge funds and other institutional investors own 89.29% of the company’s stock.

MongoDB Stock Performance

<!—->

Shares of MongoDB stock opened at $172.19 on Friday. MongoDB has a fifty-two week low of $140.78 and a fifty-two week high of $380.94. The company has a market capitalization of $13.98 billion, a P/E ratio of -62.84 and a beta of 1.49. The company has a fifty day moving average of $186.51 and a 200 day moving average of $245.99.

MongoDB (NASDAQ:MDB – Get Free Report) last issued its quarterly earnings results on Wednesday, March 5th. The company reported $0.19 earnings per share (EPS) for the quarter, missing analysts’ consensus estimates of $0.64 by ($0.45). MongoDB had a negative return on equity of 12.22% and a negative net margin of 10.46%. The business had revenue of $548.40 million during the quarter, compared to analysts’ expectations of $519.65 million. During the same quarter in the previous year, the company posted $0.86 EPS. Analysts forecast that MongoDB will post -1.78 EPS for the current year.

Analyst Upgrades and Downgrades

Several research firms have recently commented on MDB. Royal Bank of Canada dropped their target price on shares of MongoDB from $400.00 to $320.00 and set an “outperform” rating for the company in a research report on Thursday, March 6th. Rosenblatt Securities reaffirmed a “buy” rating and issued a $350.00 target price on shares of MongoDB in a research report on Tuesday, March 4th. Truist Financial dropped their target price on shares of MongoDB from $300.00 to $275.00 and set a “buy” rating for the company in a research report on Monday, March 31st. Macquarie lowered their price target on shares of MongoDB from $300.00 to $215.00 and set a “neutral” rating for the company in a research report on Friday, March 7th. Finally, China Renaissance started coverage on shares of MongoDB in a research report on Tuesday, January 21st. They set a “buy” rating and a $351.00 price target for the company. Eight equities research analysts have rated the stock with a hold rating, twenty-four have issued a buy rating and one has issued a strong buy rating to the company. Based on data from MarketBeat, the company currently has a consensus rating of “Moderate Buy” and an average target price of $294.78.

Get Our Latest Stock Analysis on MongoDB

MongoDB Company Profile

(Get Free Report)

MongoDB Target of Unusually Large Options Trading (NASDAQ:MDB) – MarketBeat

MMS • RSS

MongoDB Stock Performance

Insider Transactions at MongoDB

Hedge Funds Weigh In On MongoDB

Analyst Upgrades and Downgrades

MongoDB Company Profile

Recommended Stories

Subscribe for MMS Newsletter

Did you know...

Stock Traders Buy High Volume of MongoDB Put Options (NASDAQ:MDB) – MarketBeat

MMS • RSS

MongoDB Trading Down 1.4 %

Insider Activity at MongoDB

Institutional Investors Weigh In On MongoDB

Analyst Upgrades and Downgrades

About MongoDB

Featured Stories

Subscribe for MMS Newsletter

Did you know...

Storage news ticker – May 2 – Blocks and Files

MMS • RSS

Subscribe for MMS Newsletter

Did you know...

Presentation: Slack’s Migration to a Cellular Architecture

MMS • Cooper Bethea

Transcript

Slack’s Architecture

Cellular Design

How Things Were Done, and Choices Made

The Success Drivers

Project Cadence

When is Good Enough, Good Enough?

Where Does That Leave Us?

Do We Actually Use This Thing?

Lessons Learned

Questions and Answers

Subscribe for MMS Newsletter

Did you know...

JAT Capital Mgmt LP Sells 72,745 Shares of MongoDB, Inc. (NASDAQ:MDB) – MarketBeat

MMS • RSS

Analyst Ratings Changes

Insider Activity at MongoDB

MongoDB Trading Up 0.1 %

MongoDB Company Profile

Featured Articles

Subscribe for MMS Newsletter

Did you know...

Google Unveils Ironwood TPU for AI Inference

MMS • Steef-Jan Wiggers

About the Author

Steef-Jan Wiggers

Subscribe for MMS Newsletter

Did you know...

Podcast: Achieving Sustainable Mental Peace in Software Engineering with Help from Generative AI

MMS • John Gesimondo

Transcript

Introductions [01:09]

Using generative AI for mental peace [02:07]

Challenges of mental health in software engineering [03:20]

Overview of the Sustainable Mental Peace Framework [04:58]

Stage 1: Recovering from emotional difficulty and getting unstuck [07:24]

Stage 2: Enhancing planning and communication with AI [09:53]

Stage 3: Maximizing flow and enjoyment in Engineering Work [12:42]

Stage 4: Enabling divergent thinking and creativity [14:35]

Personal journey with neurodivergence [17:40]

The impact of formal neurodivergence recognition [21:03]

Vibe coding and the future of AI in development [24:02]

About the Author

John Gesimondo

Subscribe for MMS Newsletter

Did you know...

MongoDB Sees Unusually Large Options Volume (NASDAQ:MDB) – Defense World

MMS • RSS

MongoDB Price Performance

Wall Street Analysts Forecast Growth

Insider Activity at MongoDB

Institutional Investors Weigh In On MongoDB

About MongoDB

Featured Articles