Category: Uncategorized

To grow their career, Bruno Rey suggests that software engineers should develop ambition, increase their capacity, and seek opportunities. He advises being proactive, broadening your influence by learning from peers, and stepping outside your comfort zone. Software engineers can keep a brag doc to ensure that their work is visible and plan their growth with realistic long-term goals.

Bruno Rey spoke about how software engineers can grow their careers at QCon San Francisco.

Rey mentioned three factors that drive the personal growth of software engineers: ambition, capacity, and opportunity. Ambition for him means understanding that making an extra effort to become a better version of ourselves will pay off. Capacity is the ability to perform the tasks that are expected of an employee one level above you, or at the very least, the ability to learn it quickly. But even a perfect employee can find difficulties in climbing the ladder if they don’t find a good opportunity, Rey said.

As an individual, if you’re having trouble maintaining ambition consistently, the underlying factor might be a lack of motivation, and you should evaluate why you’re going through that, Rey suggested.

Employers and mentors should look for signs of ambition during recruiting. If you have someone working at the company who is a good worker but fails to show ambition, try to make an extra effort to explain the benefits and maybe make them see examples in real life, Rey said.

Rey suggested that software engineers have to take agency to grow personally:

Some people prefer the approach of victim-player, some call it “high-agency”, others use the term “proactive”; they’re all similar. This was made very popular with the famous “7 habits…” book by Covey, with “be proactive” being the very first habit.

We all have an area of influence, Rey said. There are things we can change and things we can’t. What happens in most cases is that engineers think that their area of influence is smaller than it actually is, and move around in the small subsection of their comfort zone:

If you’re willing to take a few uncomfortable steps, you can probably start broadening your influence by a lot. You may take a few false steps as part of this process, but if done in good spirit and with judgment, any healthy work environment should forgive those.

To broaden their influence, software engineers can talk to their manager or to a superior peer, Rey suggested. See what they do and how they operate. Try to take some tasks off their plate and do them yourself. If you don’t know how to do it, train that muscle and learn, he mentioned.

Saying “teach me how to do this” sometimes sounds lazy, so it’s better to learn as much as you can on your own and then coming to them with some specific questions or for validation that your understanding is correct, Rey said. Make sure you don’t step on their toes and don’t make your work public before getting validation from them.

To plan their career growth at a sustainable pace, software engineers should develop a long term vision:

Where do you see yourself in 3 years? And in 5 years? Make sure it’s achievable. Then trace your way back and propose intermediate goals: what do you need at the end of this year in order to achieve that 5y goal? Again, make it achievable. Discuss them with your superiors.

When planning your career, understand that things won’t always go smoothly; there will be setbacks and delays outside of your control. Just like project planning, make room to accommodate for that, Rey concluded.

InfoQ interviewed Bruno Rey about how software engineers can broaden their influence and ensure that their work is recognized.

InfoQ: How can software engineers broaden their influence?

Bruno Rey: Opportunities to broaden your influence are easier to come by in smaller companies or startups where responsibilities aren’t so segmented, and sometimes everybody does everything.

Back in 2013, I was working as a developer in one such company and would normally step out of my role and do tasks that were more associated with Ops: parse logs, restart servers/processes, or gather information about bugs. I was not afraid to just do what needed to be done, even if formally it was someone else’s task. My superiors saw this as a great trait; luckily this type of behavior was encouraged at that company.

InfoQ: What can software engineers do to ensure that their work is recognized?

Rey: Nobody gets a promotion by doing a lot of invisible work. If you want to show ambition you have to be sure that you’re vocal about the work you’re doing, even if that isn’t something that comes to you naturally.

In my case I tend to favor long tenure in jobs, and try to stay in the same company for many years to have a relevant impact. Over the years I found that a brag doc was completely necessary. Especially if you stay in the same place longer than your manager, as this helps a new manager gain context quickly on how you work and in which areas you shine.

A couple of good articles on this are Get your work recognized: write a brag document by Julia Evans and Publishing your work increases your luck by Aaron Francis.

 LTIMindtree [NSE: LTIM, BSE: 540005], a global technology consulting and digital solutions company, has announced the launch of a new business unit and suite of AI services and solutions: BlueVerse. Designed as a complete AI ecosystem, it helps enterprises accelerate their AI concept-to-value journey. This ecosystem is a universe of components that enterprises need to elevate business operations, achieve breakthrough productivity, and create transformational customer experiences.

BlueVerse Marketplace currently has over 300 industry and function-specific agents and ensures seamless interoperability and a growing connector ecosystem. It is underpinned by responsible AI governance, delivering enterprise-grade trust and scalability.

BlueVerse Productized Services utilize repeatable frameworks, accelerators, and industry-specific solution kits. At launch, BlueVerse will offer pre-built solutions for Marketing Services and Contact Center as a Service (CCaaS). With Marketing Services businesses can unlock unparalleled campaign effectiveness and achieve maximum ROI, transforming their marketing strategies into powerful growth engines. CCaaS uses context-aware AI agents to reduce response times leading to enhanced customer satisfaction.

This ecosystem also includes BlueVerse Foundry, an intuitive no-code designer and flexible pro-code editor that can enable enterprises to quickly compose and deploy AI agents, AI Tools, assistants, Retrieval-Augmented Generation (RAG) pipelines and intelligent business processes.

Venu Lambu, Chief Executive Officer and Managing Director, LTIMindtree said “BlueVerse is all about unlocking productivity for businesses at different levels by embedding AI across all functions of the enterprise. Backed by a strategic partnership ecosystem and deep AI expertise, it positions LTIMindtree as the partner of choice for future-ready organizations.”

“BlueVerse will enable our clients to unlock new sources of value, streamline operations, and stay ahead in an AI-driven world,” said Nachiket Deshpande, President, Global AI Services, Strategic Deals and Partnerships. “By embedding advanced AI across core business functions, we aim to deliver measurable outcomes and create long-term competitive advantage for our clients.”

BlueVerse is where autonomous agents and enterprise ambition converge. At LTIMindtree, we’re not just bringing AI to business—we’re making business Agentic. To learn more about BlueVerse please click here.

About LTIMindtree:

LTIMindtree is a global technology consulting and digital solutions company that enables enterprises across industries to reimagine business models, accelerate innovation, and maximize growth by harnessing digital technologies. As a digital transformation partner to more than 700 clients, LTIMindtree brings extensive domain and technology expertise to help drive superior competitive differentiation, customer experiences, and business outcomes in a converging world. Powered by 84,000+ talented and entrepreneurial professionals across more than 40 countries, LTIMindtree — a Larsen & Toubro Group company — solves the most complex business challenges and delivers transformation at scale. For more information, please visit www.ltimindtree.com.

If you’ve spent more than five minutes in web development these past few years, you’ve likely heard the MERN stack. And if not, don’t worry, let us bring you up to speed: MERN refers to MongoDB, Express.js, React, and Node.js. It’s a complete JavaScript framework that many developers are big fans of, particularly when developing speedy, cutting-edge, and responsive web apps.

But what is all the buzz about? More to the point, what are individuals actually creating with the MERN stack in the real world?

Let’s dissect five truly practical and prevalent use cases where the MERN stack excels—not just in theory, but in real products and platforms people interact with and are most used by full-stack development services.

1. Dashboards & Single Page Applications (SPAs)

Let’s begin with something that nearly every business requires: dashboards. Be it a marketing analytics dashboard, a sales CRM, or a task management application like Trello, these interfaces are ideal for the MERN stack.

You have a smooth, responsive UI that refreshes in real-time without repeatedly reloading the page with React. The backend API is driven by Express and Node, and the data is managed by MongoDB—user accounts, saved reports, activity logs, and so forth.

Why MERN works so well here:

• React makes the frontend super interactive and fast.
• MongoDB’s flexible schema is great for storing dynamic dashboard widgets or user settings.
• You can integrate real-time features like notifications or live data updates using WebSockets.

This stack is best suited for companies creating tools people utilize every day and want them to be quick, seamless, and highly responsive. 

Full-stack developers are employed on a dedicated basis by several companies to create these in-house tools from the ground up using MERN, allowing them complete control over customization and performance.

2. eCommerce Websites (Without the Bloat)

If you’ve ever used Shopify or Magento, you know that those are a bit heavyweight. That’s great for mass merchant retailing, but what is one to use when one does want something tighter or extremely proprietary?

This is where the MERN stack is a breath of fresh air.

You can create anything from a tiny online store to a marketplace website using MERN. React provides you with product pages, filters, and a responsive checkout UI. 

Express and Node take care of user authentication, payment gateway, and tracking orders. MongoDB stores all your product data, user data, reviews—you name it.

What makes it better than using a template-based CMS?

• Total control over the user experience.
• Easier to integrate custom features (e.g., flash sales, product bundles, loyalty points).
• Scales with your traffic without slowing down.

In short: if you’re tired of an eCommerce site that will ghost down in memory lane, MERN lets you build one exactly how you want it. It’s also a great fit for businesses looking for long-term, scalable full-stack development services.

3. Social Platforms & Community Sites

No, we are not saying that you’ll create the next Facebook-like app overnight—but social sites don’t need to be gigantic. Be small: writer sites, coder groups, or even interest clubs for hobbies.

The MERN stack is great for user applications with posts, comments, likes, and messaging. React enables you to build silky-smooth notification UIs and newsfeeds.

Node and Express do the back-end logic—whose friends are they, who follows whom, etc. MongoDB keeps all your unstructured content: posts, images, chat logs, and user bios.

What developers like about MERN here:

• Easy to set up real-time messaging or notifications.
• MongoDB’s document structure is ideal for social features (comments, replies, threads).
• You can add gamification, badges, or user levels easily.

If you’re building a community-first platform, MERN gives you the flexibility to grow it without outgrowing your stack.

4. Learning Management Systems (LMS)

E-learning has expanded manifold, not just because of the pandemic. People are always looking to learn at their own speed, and businesses are shelling out big money to reskill employees.

That is where Learning Management Systems come into play, and the MERN stack website development is a good fit here as well.

You can create interactive course pages, dynamically behaving video players, quizzes, and rich instructor and learner dashboards using React. 

Node and Express manage back-end logic concerning course availability, progress, and submission handling. MongoDB stores structured and semi-structured data of any type, such as course content, progress reports, ratings, and assignments.

Real advantages:

• Easily supports multiple user roles (student, teacher, admin).
• Integrates with video APIs (Zoom, Vimeo, etc.) and payment gateways.
• You can build discussion forums, certifications, and gamified elements without fighting a rigid system.

Bottom line: MERN helps you build an LMS that’s engaging, adaptable, and easy to maintain.

5. Real-Time Collaboration Tools

You’ve likely used Google Docs, Figma, or even Miro at some point. They’re sophisticated tools—but distilled to their essence, they’re about real-time collaboration.

That can be handled by the MERN stack too.

Assume that you are building a collaborative whiteboard application or a code-sharing application for developers. With React, the user interface will be refreshed in real-time for all the participants. 

Node.js using WebSockets manages the real-time data exchange between participants. Express handles routing everything in the meantime, and MongoDB manages storing the session history or version details.

Why it works:

• Node.js is great for real-time communication with many users.
• You can store and retrieve different document versions easily with MongoDB.
• React’s component model makes the UI modular and easy to update on the fly.

These kinds of apps need speed, responsiveness, and real-time capability—MERN does all three.

Wrapping Up

The MERN stack is not a silver bullet, but it certainly hits the sweet spot for a variety of web applications. From productivity applications and marketplaces to learning software and collaboration tools, it provides a rock-solid foundation that is infused with phenomenal flexibility.

If you’re going to be mapping out a project and wondering whether MERN is appropriate, think about what you’re building. Do you need something interactive? Scalable? Customizable? If the answer is yes, MERN should be a top contender.

And even if you don’t possess expertise, don’t worry—just ensure to hire extremely-committed full-stack developers who are proficient in MERN. A professional team will not only develop your application, but they will also assist you in refining it to a level that users would be willing to use.

Author Bi0

Tina Jain

Tina Jain is a tech content writer with over 3 years of experience creating clear, engaging, and SEO-friendly content. She specializes in simplifying complex technical topics for blogs, whitepapers, and product documentation, helping tech brands connect with their audiences effectively.

Introduction: Beyond the Illusion of Autonomy

Decentralized architecture is often celebrated as a technical design choice – service boundaries, team APIs, infrastructure independence. But autonomy on paper doesn’t guarantee alignment in practice.

When architecture becomes distributed, the challenge isn’t just how the system is designed – it’s how decisions get made, shared, and trusted across teams.

In my organization, that reality became clear as we grew rapidly and integrated multiple newly acquired companies.

Teams were empowered in theory, but still struggled in practice. Architects became bottlenecks. Developers either waited for permission or made decisions in isolation. Autonomy existed, but confidence didn’t.

Reading Facilitating Software Architecture by Andrew Harmel-Law gave me language – and a path – for addressing that gap.

The book offers lightweight, trust-based practices like the Architecture Advice Process, Architectural Decision Records (ADRs), and Advice Forums that help organizations build technical alignment without falling back on centralized control.

This article reflects my personal interpretation of Facilitating Software Architecture by Andrew Harmel-Law (2023), as applied in a real-world, post-acquisition engineering context.

This article shares how we’ve started applying those ideas inside a real, multi-team engineering environment. It’s not a success story – it’s a reflection on what happens when you try to shift from control to trust, from approval to advice, from isolation to visibility.

What follows is a set of lessons, tools, and cultural shifts that have helped us evolve toward a more resilient, decentralized architecture – one where autonomy is earned through shared understanding, not just granted by org charts.

The Real Problem: Decision-Making at Scale

Decentralized architecture isn’t just a matter of system design – it’s a question of how decisions get made, by whom, and under what conditions. In theory, decentralization empowers teams. In practice, it often exposes a hidden weakness: decision-making doesn’t scale easily.

We started to feel the cracks as our teams expanded quickly and our organizational landscape became more complex. As teams multiplied, architectural alignment started to suffer – not because people didn’t care, but because they didn’t know how or when to engage in architectural decision-making. Architects became bottlenecks, and developers either waited for direction or made isolated decisions that introduced long-term friction.

This problem starts earlier than many realize. Every architectural decision passes through three stages, using a simple three-stage model we found helpful:

1. A decision is required – recognizing that a choice needs to be made
2. The decision happens – evaluating options and selecting one
3. The decision is implemented – putting the decision into practice

That first stage – recognizing the decision point – is frequently missed. Too often, only one “obvious” path is presented, and the opportunity to generate or compare alternatives is skipped entirely. This makes architecture feel opaque and disempowering, especially when options are decided behind closed doors.

Even when teams do recognize a decision point, scaling the decision process across groups adds complexity. There’s no one-size-fits-all approach. What we realized is that decentralization isn’t the goal – it’s the constraint. The real objective is to make good decisions quickly, with the right people involved. That means being intentional about:

• Who can initiate, make, and implement decisions
• How we surface and compare options
• When to involve input – and from whom

Without that structure, autonomy becomes a liability.

This insight became the turning point for us. Recognizing that our decision-making model – not our tech stack – was limiting our velocity led us to adopt new practices that supported distributed decision-making without losing coherence. The first step was replacing permission-seeking with advice-seeking, which I’ll explore next.

Trust Over Control: Redefining Governance

Most engineering organizations talk about empowerment, but their architecture processes still rely on implicit control – who’s allowed to decide, who needs to sign off, and how tightly everything is tracked. For decentralization to work, that model has to change.

One model that helped clarify this shift was the Architecture Advice Process: a decision-making model grounded not in authority, but in trust.

The process follows a single rule:

Anyone can make and take an architectural decision, as long as they:

1. Seek advice from everyone meaningfully affected by the decision
2. Seek advice from experts with relevant experience

This isn’t about asking for permission. It’s about seeking knowledge, exposing context, and making informed, accountable decisions – fast.

And that shift matters. We stopped asking ‘Who approves this?’ and started asking ‘Who should I talk to before we do this?’

That reframing – away from permission and toward advice – became a cultural unlock.

We realized what we really needed wasn’t more approval – it was more clarity, more consistency, and more collaboration.

This model doesn’t mean anything goes. It relies on professionalism and mutual accountability, not hierarchy. When decision-makers seek advice visibly – and advice-givers respond with thoughtful, experience-based input – teams build trust.

By emphasizing transparency over control, we created space for better conversations, clearer ownership, and faster progress.

Putting It Into Practice: The Architecture Advice Process

The shift from control to trust requires more than mindset – it needs practice. We leaned into a lightweight but powerful toolset to make decentralized decision-making work in real teams. Chief among them is the Architectural Decision Record (ADR).

ADRs are often misunderstood as documentation artifacts. But in practice, they are confidence-building tools. They bring visibility to architectural thinking, reinforce accountability, and help teams make informed, trusted decisions – without relying on central authority.

Why ADRs Matter

Decentralized teams often face three major confidence gaps:

• Confidence in ourselves and others to make sound architectural calls
• Confidence in the advice process – that feedback was sought and considered
• Confidence in understanding decisions over time, especially when context fades

A well-crafted ADR helps close all three gaps. It gives future readers a clear view into why a decision was made, what options were considered, and who was consulted – which is critical when decisions are distributed and evolve across many teams.

What an ADR Is

An ADR captures a single architectural decision and its surrounding context. Once finalized, it’s immutable (though it can be superseded). It’s written for future teammates, not just the immediate stakeholders. It should be easy to skim for relevance or dig into for detail.

Key components include:

• Title & ID – Clear and uniquely identifiable
• Status & Date – Indicates when the decision was made
• Context – Explains the problem or trigger
• Options – Lists 3–5 real, thoughtful alternatives – not just strawmen
• The decision outcome – Names the option chosen and why
• Advice Received – Captures raw advice from those consulted

Don’t exclude rejected options – “Do nothing” counts too – rejection is still a decision

This structure isn’t just for record-keeping. It reinforces the Architecture Advice Process by tying decision-making directly to the advice that informed it.

Making ADRs Work in Practice

In my own organization, architectural decisions often lived in Slack threads or hallway conversations – easy to lose, hard to revisit. We were informally applying parts of the advice process, but without structure or visibility. Introducing even a lightweight, markdown-based ADR process brought immediate clarity.

Some practices that helped us:

• Start with the problem. Brain-dump the context before listing solutions.
• Seek advice early. Especially on the framing and scope – not just the options.
• Make it visible. Share who was consulted and what was learned.
• Capture provisional decisions. These invite feedback without stalling progress.

Storing ADRs close to the work – in GitHub repos, internal wikis, or project docs – makes them accessible. We treat them as a living archive of architectural thinking, not just decisions.

More Than Documentation

What stood out most to me is that ADRs aren’t just about record-keeping – they’re about trust. They help bridge the gap between those who design systems and those who live with the consequences of decisions. They give new teammates a path into prior decisions, and help avoid repeating the same conversations.

Most importantly, ADRs reflect the culture shift behind advice-driven architecture. They show teams that decisions aren’t made in isolation or by decree, but through transparent, inclusive, and intentional processes.

Creating Shared Context with Advice Forums

Decentralized architecture works best when decisions don’t happen in isolation. Even with good individual practices – like ADRs and advice-seeking – teams still need shared spaces to build trust and context across the organization. That’s where Architecture Advice Forums come in.

We implemented a practice called the advice forums that offer a lightweight structure to support decentralized decision-making without reintroducing control. They aren’t governance checkpoints. They’re opportunities to learn, align, and advise – openly and regularly.

What an Advice Forum Is (and Isn’t)

An advice forum is:

• A recurring session for discussing in-progress architectural decisions
• A forum for advice, not approvals or consensus
• A place where teams present, experts advise, and observers learn

It’s not about gatekeeping or slowing teams down. Instead, it provides transparency and distributed visibility into architectural thinking – especially helpful in organizations with multiple teams or domains.

The Forum’s Core Purposes

Advice forums serve three main goals:

1. Increase visibility into decisions already in flight
2. Build trust through transparent, real-time discussion
3. Create learning moments for participants and observers alike

When these conversations happen in the open, they promote psychological safety, sharpen thinking, and reduce the risk of duplicated effort. It also reinforces accountability – teams that know they’ll be sharing their work tend to think more intentionally about how they frame and justify decisions.

How It Works

Forums are structured but informal:

• Agendas are shared in advance with links to draft ADRs
• Teams briefly present the decision, context, and areas where they’re seeking input
• Advice is offered in the moment or afterward – always recorded in the ADR
• Silence is treated as intentional non-participation, not passive approval

Crucially, no decisions are made in the forum itself. The responsibility to decide remains with the team closest to the work. But the forum amplifies support, challenges blind spots, and exposes patterns worth exploring more broadly.

Why This Works

What makes this practice effective isn’t the meeting – it’s the mindset:

• It normalizes open architectural thinking, not behind-the-scenes approvals
• It enables cross-team alignment without enforcing sameness
• It fosters a community of curiosity, not control

Concepts like coalescent argumentation – where groups acknowledge shared understanding before exploring disagreements – help keep conversations productive. Teams learn not just what others are deciding, but how they’re thinking, what trade-offs they considered, and why they landed where they did.

In my own reflections, I found this practice particularly compelling. In many organizations, great technical work happens in silos. Advice forums help break those silos without imposing heavyweight processes. They create a visible on-ramp for developers and teams who want to engage with architecture but don’t yet feel empowered to do so.

Tips for Implementation

To get started, you don’t need buy-in from the whole company. Start small:

• Create a shared ADR template and repository
• Define the forum’s scope and expectations clearly – e.g., a one-page Terms of Reference
• Emphasize learning and delivery over ceremony
• Keep it optional but valuable

When done well, advice forums become a hub of architectural awareness. They help organizations evolve from disconnected teams making isolated decisions to a culture where architecture is open, shared, and continuously improved.

From Approval to Alignment: Cultural Shifts Observed

The shift to advice-seeking changed more than our process – it changed how people behaved.

Before adopting the Architecture Advice Process, our architecture function had become a bottleneck. Teams waited. Architects felt overwhelmed. Decisions often landed in our laps too late or with too little context. Everyone waited for someone else to make a decision. The more the architects centralized, the less connected they became.

We were holding too much, and holding it too tightly. And it showed, Teams felt stuck. Architects felt responsible for decisions they weren’t close enough to make well.

We replaced approval bottlenecks with a system of shared responsibility. Teams began to proactively explain their decisions, involve the right people, and build more confidence in the process. Not everything shifted overnight, but over time, these patterns emerged:

• More developers wrote ADRs, even for small or internal decisions
• Architects stopped defaulting to ownership and started focusing on support
• Conversations got more thoughtful and less political

This wasn’t just a process change. It was a behavioral reset – a shift from permission to presence, from control to coaching. And it created space for a more inclusive, transparent, and resilient architecture practice.

Conclusion: A Cohesive Culture of Autonomy

Decentralized architecture only works when it’s grounded in intentional practices. Tools like the Architecture Advice Process, ADRs, and advice forums don’t just help us move faster – they help us move together.

One of the clearest lessons from both my experience and Harmel-Law’s book is this:

“Distributed architecture is more social than technical.”

It’s not enough to distribute system responsibilities – you also have to distribute trust. That means replacing command-and-control with guidance and transparency. It means shifting the architect’s role from approval authority to trusted peer and visible collaborator.

“Architects don’t need more power. They need more presence.”

If you’re working in a growing or distributed organization, consider piloting one of these practices. Start small. Try a lightweight ADR template. Launch a casual advice forum. Shift one decision from approval to advice.

Decentralization isn’t just an architectural pattern – it’s a cultural commitment. And it starts with how we choose to decide.

Farther Finance Advisors LLC boosted its stake in MongoDB, Inc. (NASDAQ:MDB – Free Report) by 57.2% during the 1st quarter, according to its most recent Form 13F filing with the Securities and Exchange Commission (SEC). The institutional investor owned 1,242 shares of the company’s stock after acquiring an additional 452 shares during the period. Farther Finance Advisors LLC’s holdings in MongoDB were worth $219,000 at the end of the most recent reporting period.

Several other institutional investors have also recently added to or reduced their stakes in MDB. Vanguard Group Inc. raised its holdings in shares of 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 purchasing an additional 23,942 shares during the period. Franklin Resources Inc. raised its holdings in shares of MongoDB by 9.7% during the fourth quarter. Franklin Resources Inc. now owns 2,054,888 shares of the company’s stock worth $478,398,000 after purchasing an additional 181,962 shares during the period. Geode Capital Management LLC raised its holdings in shares of MongoDB by 1.8% during the fourth quarter. Geode Capital Management LLC now owns 1,252,142 shares of the company’s stock worth $290,987,000 after purchasing an additional 22,106 shares during the period. First Trust Advisors LP raised its holdings in shares of MongoDB by 12.6% during the fourth quarter. First Trust Advisors LP now owns 854,906 shares of the company’s stock worth $199,031,000 after purchasing an additional 95,893 shares during the period. Finally, Norges Bank acquired a new stake in shares of MongoDB during the fourth quarter worth $189,584,000. 89.29% of the stock is owned by institutional investors and hedge funds.

Insider Activity

In related news, CEO Dev Ittycheria sold 25,005 shares of the business’s stock in a transaction on Thursday, June 5th. The shares were sold at an average price of $234.00, for a total transaction of $5,851,170.00. Following the transaction, the chief executive officer now owns 256,974 shares of the company’s stock, valued at approximately $60,131,916. The trade was a 8.87% decrease in their ownership of the stock. The sale was disclosed in a legal filing with the SEC, which is available through this hyperlink. Also, Director Dwight A. Merriman sold 2,000 shares of the business’s stock in a transaction on Thursday, June 5th. The stock was sold at an average price of $234.00, for a total transaction of $468,000.00. Following the transaction, the director now directly owns 1,107,006 shares in the company, valued at $259,039,404. This trade represents a 0.18% decrease in their position. The disclosure for this sale can be found here. Insiders have sold a total of 49,208 shares of company stock valued at $10,167,739 over the last 90 days. 3.10% of the stock is currently owned by company insiders.

MongoDB Price Performance

NASDAQ MDB opened at $204.15 on Thursday. The company has a 50 day simple moving average of $184.32 and a 200-day simple moving average of $223.66. The firm has a market capitalization of $16.68 billion, a price-to-earnings ratio of -179.08 and a beta of 1.39. MongoDB, Inc. has a 52-week low of $140.78 and a 52-week high of $370.00.

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

Wall Street Analyst Weigh In

Several equities analysts have recently commented on the stock. Loop Capital lowered shares of MongoDB from a “buy” rating to a “hold” rating and lowered their price target for the stock from $350.00 to $190.00 in a research report on Tuesday, May 20th. DA Davidson restated a “buy” rating and set a $275.00 price target on shares of MongoDB in a research report on Thursday, June 5th. Wells Fargo & Company lowered shares of MongoDB from an “overweight” rating to an “equal weight” rating and lowered their price target for the stock from $365.00 to $225.00 in a research report on Thursday, March 6th. KeyCorp lowered shares of MongoDB from a “strong-buy” rating to a “hold” rating in a research report on Wednesday, March 5th. Finally, Bank of America upped their price target on shares of MongoDB from $215.00 to $275.00 and gave the stock a “buy” rating in a research report on Thursday, June 5th. Eight research 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 stock. According to data from MarketBeat, the stock has a consensus rating of “Moderate Buy” and an average target price of $282.47.

Read Our Latest Stock Analysis on MDB

MongoDB Profile

(Free Report)

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

See Also

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

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

Cohesity announced a deeper integration with MongoDB, the leading database for modern applications. The new integration provides advanced performance and control capabilities for backup and recovery of MongoDB databases. Cohesity is among the first data protection software providers to deliver MongoDB workload protection through the MongoDB Third Party Backup Ops Manager API.

Designed with large, critical datasets in mind, the integration supports the strict resilience requirements of global banking, financial services, and Fortune 500 enterprises. The integration is currently available for Cohesity DataProtect. Cohesity research finds organizations overestimate their cyber resilience capabilities and maturity–often overlooking deficiencies in data recovery speed and capabilities.

In fact, only 2% of respondents in a global survey said they could recover data and restore business processes within 24 hours if a cyberattack occurred. The performance and control capabilities enabled through Cohesity’s deepened integration with MongoDB supports customers in meeting stringent recovery point and recovery time objectives. Advanced capabilities include: Greater speed – parallel data streams enable billions of objects to be processed instantaneously.

At the same time, Cohesity’s intelligent backups can get customers’ MongoDB databases back online 4X faster than traditional methods. Robust scalability- a scale-out architecture provides petabyte-sized support on a single platform. Customers can reduce their data footprint with global, variable-length deduplication and compression.

Enhanced security – immutable write once, read many (WORM) storage, data encryption in flight and at rest, continuous data protection, secure SSL authentication, and a multi-layer defense posture based on Zero Trust security principles offer additional security enhancements.

Cohesity has announced an expanded integration with MongoDB to deliver enhanced data protection and recovery performance for large enterprise workloads.

The deepened integration allows Cohesity customers to utilise the MongoDB Third Party Backup Ops Manager API, offering new controls and capabilities tailored to scenarios involving extensive datasets and stringent resilience requirements. This is particularly targeted at sectors such as financial services and the global banking industry, alongside Fortune 500 organisations, that demand minimal downtime and heightened security.

According to Cohesity, this functionality is now available for users of its DataProtect solution. By leveraging the new API-based integration, the company states that enterprises can better address data recovery speed and backup process efficiencies.

Cyber resilience focus

Vasu Murthy, Senior Vice President and Chief Product Officer at Cohesity, commented on the growing challenges faced by large organisations due to the increasing threat of ransomware attacks and the related business risks.

“With ransomware attacks now commonplace, cyber resilience is a strategic priority for all organisations. This is particularly true of large enterprises, which have a very low tolerance for risk,” said Vasu Murthy. “Downtime for any reason can mean millions of dollars and massive reputational damage. As trusted providers for many of the world’s largest companies, Cohesity and MongoDB are working together to strengthen our customers’ ability to bounce back fast.”

This expanded partnership between Cohesity and MongoDB aims to address the growing need for robust, enterprise-grade data protection. Paul Henaghan, Managing Director, Cohesity, Australia and New Zealand, highlighted the benefits for institutions across the region in the context of the evolving cyber threat environment.

“In today’s cyber threat landscape, organisations across Australia and New Zealand require data resilience that goes beyond basic backup, especially among large enterprises with complex technology environments and systems. Our expanded integration with MongoDB gives customers the enterprise-grade speed, scale and security needed to confidently protect and recover their most vital workloads. This is a powerful step forward in helping ANZ businesses reduce downtime risk and maintain trust in the face of escalating cyber threats,” said Paul Henaghan.

Industry research and capabilities

Cohesity’s own research indicates a gap between organisations’ perceived and actual cyber resilience. Only a small fraction—2%—of participants in a global survey reported being able to recover data and restore business processes within 24 hours following a cyberattack. The company suggests that the new MongoDB integration helps close this gap for customers seeking to meet rigorous recovery point and time objectives.

Some of the advanced features introduced through this integration include improved speed, as parallel data streams allow for the simultaneous processing of billions of objects. Cohesity states that intelligent backups can bring MongoDB databases online four times faster than traditional approaches. The system also boasts a scale-out architecture capable of accommodating petabyte-sized workloads on a single platform, introducing efficiencies such as global, variable-length deduplication and compression to reduce data footprint.

Additional security measures include support for immutable write once, read many (WORM) storage, end-to-end data encryption, continuous data protection, and secure SSL authentication—all underpinned by Zero Trust principles and a multi-layered defence model.

Collaborative efforts

Representatives from MongoDB and its partners echoed the significance of the collaboration. Benjamin Cefalo, Senior Vice President of Product Management at MongoDB, highlighted the broader mission of supporting performance and agility without sacrificing enterprise resilience.

“As the leading document database for modern applications, MongoDB empowers organisations to build, scale, and innovate faster,” said Benjamin Cefalo. “Our collaboration with Cohesity reinforces that mission by helping customers protect their data with robust, enterprise-grade resilience—without compromising the agility and performance developers expect from our platform.”

Juan Orlandini, Chief Technology Officer for North America at Insight, commented on the immediate applicability of these improvements to large organisations operating with critical datasets.

“Cohesity continues to broaden and enhance its support for enterprise workloads, including those with critical customer datasets at petabyte scale. The deepened integration with MongoDB addresses the most pressing data security concerns for large enterprises and financial organisations by delivering the speed, scalability, and security they require.”

Market demand

The integration between Cohesity and MongoDB is geared towards organisations with large-scale, mission-critical database workloads that cannot afford significant interruptions. Cohesity cites ongoing demand among its global enterprise customer base, which includes over 85 of the Fortune 100 and nearly 70% of the Global 500, for enhanced backup and recovery processes.

Deno Land recently released Deno 2.3, an update of the Deno runtime that adds support for local NPM packages. Deno 2.3 also brings improvements to deno compile.

Deno 2.3 makes testing and developing an npm package locally possible. Deno thus provides mechanisms to override dependencies, enabling developers to use custom or local versions of libraries. The mechanism is similar to npm link in Node.js, and is configured through the patch field in deno.json:

{
  "patch": [
    "../path/to/local_npm_package"
  ]
}

Developers can review the provided example.

deno compile compiles a project into a single standalone binary, thus facilitating the executable distribution. This allows distributing Deno applications to systems that do not have Deno installed. Under the hood, it bundles a slimmed-down version of the Deno runtime along with the JavaScript or TypeScript code.

Deno 2.3 extends deno compile to support programs that use Foreign Function Interface (FFI) and Node native add-ons. FFI provides a bridge between Deno’s JavaScript runtime and native code, allowing developers to use existing native libraries within Deno applications, implement performance-critical code in languages like Rust or C, or access operating system APIs and hardware features not directly available in JavaScript.

Developers can additionally now reduce the size of executables by excluding specific files from being embedded during the compilation process (e.g., exclude development or test files from production builds).

To upgrade to Deno 2.3, developers need simply run the following command in the terminal:

deno upgrade

Deno 2.3 includes additional features, including improvements to deno fmt (allowing developers to format embedded CSS, HTML, and SQL in tagged templates), expanded OpenTelemetry support (basic event recording, span context propagators, and more), faster dependency installation, and more. For the full list of features, developers are invited to review the release note.

Deno is open-source software that is available under the MIT license. Contributions are encouraged via the Deno Project and should follow the Deno contribution guidelines.