Category: Uncategorized

Posted on mongodb google news. Visit mongodb google news

Bank of Nova Scotia lessened its position in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 100.0% during the fourth quarter, according to the company in its most recent 13F filing with the Securities & Exchange Commission. The fund owned 11,640 shares of the company’s stock after selling 26,995,360 shares during the period. Bank of Nova Scotia’s holdings in MongoDB were worth $2,708,000 as of its most recent SEC filing.

Other hedge funds also recently made changes to their positions in the company. Hilltop National Bank lifted its holdings in MongoDB by 47.2% in 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 last quarter. NCP Inc. acquired a new stake in shares of MongoDB during the 4th quarter worth approximately $35,000. Wilmington Savings Fund Society FSB bought a new stake in shares of MongoDB in the 3rd quarter worth approximately $44,000. Versant Capital Management Inc boosted its position in MongoDB by 1,100.0% during the 4th quarter. Versant Capital Management Inc now owns 180 shares of the company’s stock valued at $42,000 after purchasing an additional 165 shares during the period. Finally, Morse Asset Management Inc bought a new position in MongoDB during the 3rd quarter worth $81,000. Institutional investors and hedge funds own 89.29% of the company’s stock.

Analyst Ratings Changes

MDB has been the subject of several analyst reports. Cantor Fitzgerald assumed coverage on shares of MongoDB in a report on Wednesday, March 5th. They set an “overweight” rating and a $344.00 price target for the company. The Goldman Sachs Group reduced their target price on shares of MongoDB from $390.00 to $335.00 and set a “buy” rating for the company in a research note on Thursday, March 6th. Stifel Nicolaus cut their price target on MongoDB from $340.00 to $275.00 and set a “buy” rating on the stock in a report on Friday. Macquarie decreased their price objective on MongoDB from $300.00 to $215.00 and set a “neutral” rating for the company in a report on Friday, March 7th. Finally, KeyCorp downgraded MongoDB from a “strong-buy” rating to a “hold” rating in a research note on Wednesday, March 5th. Seven investment analysts have rated the stock with a hold rating, twenty-four have issued a buy rating and one has assigned a strong buy rating to the stock. Based on data from MarketBeat.com, the stock has a consensus rating of “Moderate Buy” and an average price target of $310.74.

Read Our Latest Report on MongoDB

Insider Activity

In related news, Director Dwight A. Merriman sold 1,045 shares of the firm’s stock in a transaction that occurred on Monday, January 13th. The shares were sold at an average price of $242.67, for a total transaction of $253,590.15. Following the completion of the sale, the director now directly owns 85,652 shares in the company, valued at approximately $20,785,170.84. This trade represents a 1.21 % decrease in their ownership of the stock. The transaction was disclosed in a document filed with the SEC, which can be accessed through the SEC website. Also, CEO Dev Ittycheria sold 18,512 shares of the company’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 transaction of $3,207,389.12. Following the completion of the transaction, the chief executive officer now owns 268,948 shares in the company, valued at approximately $46,597,930.48. This represents a 6.44 % decrease in their position. The disclosure for this sale can be found here. Over the last quarter, insiders have sold 58,060 shares of company stock worth $13,461,875. 3.60% of the stock is owned by corporate insiders.

MongoDB Trading Up 0.7 %

NASDAQ MDB opened at $162.24 on Friday. MongoDB, Inc. has a 1 year low of $140.78 and a 1 year high of $387.19. The stock’s 50-day moving average price is $220.46 and its two-hundred day moving average price is $256.10. The company has a market cap of $13.17 billion, a PE ratio of -59.21 and a beta of 1.49.

MongoDB (NASDAQ:MDB – Get Free Report) last issued 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 net margin of 10.46% and a negative return on equity of 12.22%. The firm had revenue of $548.40 million during the quarter, compared to analysts’ expectations of $519.65 million. During the same quarter last year, the company posted $0.86 EPS. Research analysts forecast that MongoDB, Inc. will post -1.78 EPS for the current fiscal year.

MongoDB Profile

(Free Report)

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

Read More

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

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

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

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

View The Five Stocks Here

Need to stretch out your 401K or Roth IRA plan? Use these time-tested investing strategies to grow the monthly retirement income that your stock portfolio generates.

Get This Free Report

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

Article originally posted on InfoQ. Visit InfoQ

This week’s Java roundup for April 7th, 2025 features news highlighting: milestone releases of Spring AI 1.0 and Spring Cloud 2025; beta releases of Open Liberty 2025.0.0, Hibernate Reactive 3.0 and LangChain4j 1.0; and the sixth release candidate of Vert.x 5.0.

JDK 25

Build 18 of the JDK 25 early-access builds was made available this past week featuring updates from Build 17 that include fixes for various issues. More details on this release may be found in the release notes.

For JDK 25, developers are encouraged to report bugs via the Java Bug Database.

Jakarta EE

In his weekly Hashtag Jakarta EE blog, Ivar Grimstad, Jakarta EE Developer Advocate at the Eclipse Foundation, provided an update on Jakarta EE 11 and Jakarta EE 12, writing:

We are getting closer and closer to finalizing the refactoring of the Jakarta EE Platform TCK. The goal right now is to have the Jakarta EE 11 Platform ready for release review by the end of May 2025. Stay tuned for updates.

Plan reviews for Jakarta EE 12 are going on as we speak. Check out the progress in the Jakarta EE 12 Plan Review status board. My guess is that we will see quite a few more coming forward as the April 15 deadline is fast approaching.

The road to Jakarta EE 11 included four milestone releases, the release of the Core Profile in December 2024, the release of Web Profile in April 2025, and a fifth milestone and first release candidate of the Platform before its anticipated release in 2Q 2025.

Spring Framework

The seventh milestone release of Spring AI 1.0.0 features several breaking changes that align with the structural improvements to “create a more modular and maintainable codebase while reducing unnecessary dependencies in your applications.” Core architecture improvements include: a comprehensive modular architecture; modular autoconfiguration; package reorganization; and framework enhancements. This will be the last milestone release as the team plans a release candidate and the GA release in time for the Spring I/O conference in May 2025.

The third milestone release of Spring Cloud 2025.0.0, codenamed Northfields, features bug fixes and notable updates to sub-projects: Spring Cloud Kubernetes 3.3.0-M3; Spring Cloud Function 4.3.0-M2; Spring Cloud Stream 4.3.0-M3; and Spring Cloud Circuit Breaker 3.3.0-M3. This release is based upon Spring Boot 3.5.0-M3. More details on this release may be found in the release notes.

Versions 4.3.0-M3, 4.2.1, 4.1.6, 4.0.10 and 3.1.10 of Spring Cloud Config have been released to address CVE-2025-22232, a vulnerability where, under certain conditions, the Spring Cloud Config server may not use the Spring Cloud Vault token sent by clients using a X-CONFIG-TOKEN header.

WildFly

The release of WildFly 36 delivers notable features such as: support for MicroProfile 7.0; experimental support to launch WildFly from JBang; improvements to the WildFly AI Feature Pack; support for the Prometheus Registry in the micrometer extension; and enhancements to the WildFly documentation page. More details on this release may be found in the release notes.

Open Liberty

IBM has released version 25.0.0.4-beta of Open Liberty featuring support for JDK 24; a file-based health check mechanism with MicroProfile Health as an alternative to the traditional /health endpoints; and InstantOn support for the J2EE Management 1.1, Application Client Support for Server 1.0, Jakarta Application Client Support for Server 2.0 and Web Security Service 1.1 features.

Hibernate

The third beta release of Hibernate Reactive 3.0.0 ships with: the additional of an upsertAll() and upsertMultiple() methods to the implementation of the Hibernate ORM StatelessSession interface; and a resolution to an UnexpectedAccessToTheDatabase exception upon merging a detached entity with annotated with @OneToMany or @ManyToMany. This release is compatible with Hibernate ORM 7.0.0-M5. More details on this release may be found in the release notes.

Eclipse Vert.x

The sixth release candidate of Eclipse Vert.x 5.0.0 provides new features such as: support for the Java Platform Module System (JPMS); and a new VerticleBase class that replaces the deprecated AbstractVerticle class due to the removal of the callback asynchronous model in favor of the future model. The team anticipates the GA release to be available in May 2025. More details on this release may be found in the release notes and list of deprecations and breaking changes.

Apache Tomcat

Versions 11.0.6 and 9.0.104 of Apache Tomcat (announced here and here, respectively), deliver new features: the Java Runtime Environment (JRE) in no longer required to provide an implementation of the Message-Digest Algorithm (MD5) specification; improvements to the JsonErrorReportValve class that eliminates a NullPointerException; and improved handling of the %nn URL encoding in the RewriteValve class. More details on these releases may be found in the release notes for version 11.0.6 and version 9.0.104.

LangChain4j

The third beta release of LangChain4j 1.0.0 provide notable changes such as: support for additional return types in the JSON schema of Structured Outputs; and support for streaming and observability in Amazon Bedrocks. Breaking changes include the removal of several deprecated interfaces that include ChatModelRequest and ChatModelResponse. More details on this release may be found in the release notes.

Posted on mongodb google news. Visit mongodb google news

Every morning, find a selection of analysts’ recommendations covering North America and the UK. The list only includes companies that have been the subject of a change of opinion or price target, or of a new coverage. It may be updated during the session. This information can be used to shed light on movements in certain stocks or on market sentiment towards a company.

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

Article originally posted on InfoQ. Visit InfoQ

Software, its size, its requirements, and its infrastructure environment evolve over time. Software architecture should evolve accordingly. Otherwise, we risk an architecture that no longer meets current and future operational and developmental requirements. We even risk the ability to implement feature changes and additions. Fitness functions are guardrails that enable continuous evolution of your system’s architecture, within a range and a direction, that you desire and define.

What are fitness functions?

Fitness functions come in various flavors and are applicable in different domains. Let’s focus on fitness functions for software here, more precisely software architecture. I like to use the definition from the book, Building Evolutionary Architectures, by Neal Ford, Rebecca Parsons, Patrick Kua, and Pramod Sadalage: “An architectural fitness function is any mechanism that provides an objective integrity assessment of some architectural characteristic(s)”.

In case that reads too vaguely: fitness functions offer us self-defined guardrails for certain aspects of our architecture. If we stay within certain (self-chosen) ranges, we’re safe (our architecture is “good”). If we’re outside those ranges we get fast feedback in our build pipeline, for example, or even faster if we run the fitness functions locally on our development machine. Developers and architects can react quickly, fix the violations, and make the code “fit” again.

An objective measure of each fitness function is important! Measurements and measures should not be based on personal opinion. For instance, “readability” is probably not a good fitness function: “Your code does not look readable to me. I’d write it differently”.

Objective numbers are a better choice: “We have 17 violations which is within our tolerable range of up to 20 violations. So we’re good for now. Let’s talk about changing the tolerable range to allow only 10 violations for the next iteration”. Or “We found two unwanted dependencies between the modules. We must remove these dependencies”. These measurements are objective, based on numbers. Possible actions are clear.

The purpose of fitness functions in evolutionary architectures

Fitness functions are the essential foundation for evolutionary architectures: They enable evolution in an advantageous direction. We can define what “advantageous” means in our context.

There will always be deviations in systems, and changes to the code, the architecture, and the product. Good changes (the ones that we need for the future, for the “survival” of our software) as well as bad changes that might endanger the viability of our system.

Fitness functions help us decide which deviations or changes are acceptable, which can be tolerated for the time being, and which deviations or changes we should revert. In that respect, architectural fitness functions are similar to unit tests. While the latter are used to assert certain characteristics of our domain code, the former are tests for our architecture. Of interest, there are tools that allow us to write architectural fitness functions in a unit test style.

Some examples of using fitness functions

Many projects already use some kinds of fitness functions, although they might not use the term. For example, metrics from static code checkers, linters, and verification tools (such as PMD, FindBugs/SpotBugs, ESLint, SonarQube, and many more). Collecting the metrics alone doesn’t make it a fitness function, though. You’ll need fast feedback for your developers, and you need to define clear measures: limits or ranges for tolerated violations and actions to take if a metric indicates a violation.

In software architecture, we have certain architectural styles and patterns to structure our code in order to improve understandability, maintainability, replaceability, and so on. Maybe the most well-known pattern is a layered architecture with, quite often, a front-end layer above a back-end layer. To take advantage of such layering, we’ll allow and disallow certain dependencies between the layers. Usually, dependencies are allowed from top to down, i.e. from the front end to the back end, but not the other way around. A fitness function for a layered architecture will analyze the code to find all dependencies between the front end and the back end. This function will issue a warning or maybe even “break” (stop) the build if it finds a dependency from the back end to the front end.

For example, a simple fitness function to assert correct layering might look like this:

noClasses()
  .that().resideInAPackage("..backend.".)
  .should().dependOnClassesThat().resideInAPackage("..frontend.".);

I’ve used ArchUnit for Java for most of the examples shown here. ArchUnit is a small library that you include as usual as a dependency on your project. The ArchUnit fitness functions, or “rules”, can be executed by any unit testing framework; there is a convenient integration into JUnit.

If you have more layers, this simple approach will become cumbersome. For such cases, ArchUnit offers predefined rule sets like layeredArchitecture(), where defining your structures becomes more declarative, less tedious, and less error-prone. JMolecules, a library that builds upon ArchUnit (and other tools), goes even further, allowing you to put tags (markers) onto your structures (package Annotations in Java). Executing the fitness function becomes an expression as simple as

JMoleculesArchitectureRules.ensureLayering();

JMolecules is the Java implementation of the xMolecules project, which is available for .NET and PHP as well.

There are other styles and patterns, like vertical “slices”, which better support domain-based architectures. There are also inside-outside patterns like “hexagonal” and “clean” as well as “onion” architectural styles, where the idea is to separate the (domain) core of your application, which is under your control, from the outside world (external systems) that often you cannot control as much. We can easily write fitness functions for the allowed and disallowed dependencies that enforce the respective patterns.

For example, to assess that our vertically sliced domains are free of cyclic dependencies, we could write an ArchUnit fitness function as follows:

slices()
  .matching("com.myapp.(*).".)
  .should().beFreeOfCycles();

We can even combine these patterns and implement multiple fitness functions. Quite often that makes sense, depending on your context.

Not only can we use fitness functions for the dependencies between structures, we can also use them to improve the code design within one structure. If, for example, the architects intend to make the API of existing modules independent from implementation details, we could write an ArchUnit fitness function like

noClasses()
  .that().resideInAPackage("..api.".)
  .should().dependOnClassesThat().resideInAPackage("..impl.".);

You’ll find more examples on the projects’ web pages. I’ve collected some examples in my GitHub repo as well.

How fitness functions and agility relate to each other

Agility is the ability to quickly adapt to change. This ability requires a certain fitness, in both nature (imagine a gazelle) and sports, as well as in software architecture. If your software products lack the necessary fitness, the need to move quickly (i.e. the need to implement changing requirements) leads to pain, stumbling, and deterioration.

Fitness functions help us gain and maintain fitness in certain aspects that we consider critical for the evolvability of our systems. This way, they enable agility on an architectural level. And that’s interesting, because changing (evolving) the architecture of a currently successful software system often clashes with how governance is implemented in many larger companies. Governance is seen as an obstacle to change, an impediment to agility.

But governance is probably not the problem, long and slow feedback loops are. If your developers get feedback on violations in their code, in their implementation of the desired architecture, weeks or even months after they’ve worked on a feature, you will earn their frustration.

Fitness functions “shift left” governance to the development teams to give them fast feedback, while they’re working on the code. That shift shortens the feedback loop dramatically. Governance might even be seen as an “enabler” for agility, because suddenly it becomes a safety net that springs into action.

We don’t need late inspections; instead, teams can ensure compliance with our architectural guidelines right from the start, in an agile way. Playing with a famous quote: You can’t inspect (architectural) fitness into a frail system, it must be built into it.

Bridging the gap between architects and software developers

Large enterprises tend to prescribe architectural rules from somewhere “above”. That approach often does not work well and yields unnecessarily complex systems, because developers will not understand the intent of the rules and the big picture of the enterprise architecture.They will unintentionally write code that undermines the objective of the rules.

Small startups or “agile shops” tend to ignore architectural rules or leave architecture decentralized to hopefully capable developers in their respective teams. This lack of awareness can easily lead to architectural chaos. Again, a big picture of an overall architecture is easily missed.

The best architects I’ve met offer guidance, not prescription. They offer a direction in which to think and to design the code. With fitness functions, architects can write their intentions into executable code. Even better, architects and developers can discuss their architectural rules together and the developers can write the fitness functions themselves. This collaboration fosters communication about architecture and the intent (and meaningfulness) of certain rules.

By “shifting left” the assessment of architectural characteristics into the development teams, architecture becomes a concern of all the people involved in building the software, rather than a few in certain positions or job descriptions. By implementing this approach, architects can focus on explaining and teaching and can keep an eye on the overall architecture. Architecture becomes a role that many people can take: developers as well as architects. This approach closes the gap between architects and software developers step by step, fitness function by fitness function.

Architecture as a team sport – not limited to architecture teams

Fitness functions take architecture out of its silo, out of the heads of fixed job positions. Now, all the people involved in software development are concerned with a viable architecture and its further evolution.

Fitness functions are simultaneously safety net, documentation, and architectural evolution enabler. Because many brilliant people now regularly think about architecture and its implementation in code, the architecture improves, not only within the products, but overall.

Another thing I noticed when architects and developers collaborated on fitness functions: those teams and departments usually worked in an atmosphere of creativity and innovation. I’m not sure if fitness functions are the cause or the consequence, but there probably is a correlation.

Fitness functions – a silver bullet?

It almost sounds too good to be true. Shouldn’t every project and every team use fitness functions then? Well, more and more are, at least in my observation. However, their use is often confined to the more obvious structural fitness functions that we saw above.

It’s rather hard to identify and define good fitness functions apart from the structural ones, especially with regards to if a function is violated for:

• Runtime behaviors such as network traffic between services
• Properties of data products like adherence to data contracts
• Output of GenAI solutions to stay within certain ranges

It’s definitely possible to define good fitness functions, but it requires some experience, some experimentation, and sometimes some unconventional ideas. So, starting with the easier structural fitness functions is a good choice. There might be areas where having fitness functions in place is an obstacle rather than a useful tool. Consider the three stages of product innovation and development:

• Explore the domain
• Build the right thing
• Build the thing right

If you’re in the first stage and you don’t know the direction yet, fitness functions might impose too much unwanted direction. But in the second stage, using fitness functions might make sense already, although you might want to use rather broad guardrails. These guardrails may be narrowed in the third stage, where the desired direction should be clearer.

Alternatives to using fitness functions

Of course, we managed to build software systems for many years without the use of fitness functions. So we can always fall back to the previous way to assert architectural compliance: conducting architecture reviews and assessments. This might still be a valid choice, for example, if someone requires such explicit events. You can always do this in addition to using fitness functions, which might yield even better architecture implementations and understanding.

As these manual reviews and assessments are usually not (completely) automated, they come at the cost of speed and scalability. Companies that prefer architecture reviews and assessments usually have a centralized architecture, defined (and controlled) by an architecture team with a limited number of people.

If you see your architecture as static or you deliberately need to be slow in changing the architecture, manual reviews might be your first choice. Using fitness functions will still protect you from unwanted deviations from your target architecture.

Bottom line

If you haven’t heard of fitness functions yet or haven’t used them so far, it might be worth looking into them. They might not be suitable for each and every project, but most projects will benefit from using fitness functions in one or the other way, especially if maintenance is required over many years.

Fitness functions keep our software and its architecture “soft”, and continuously evolvable. This matters because change is not the exception, but the rule. Having some kind of guardrails gives us safety to implement changes in existing, successful software systems, which makes evolutionary architecture possible.

Even if you cannot use the libraries that I presented in this article, the concept of fitness functions is independent of programming languages and technologies.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Potvin: This is my kid’s favorite family photo, and it is not mine. I am not a rollercoaster person, but I’m using this just as a representation for a time about two years ago when I was really not having fun, and it felt like quite an emotional rollercoaster. I was doing what I thought was my dream job, what I always wanted. I was VP of engineering at GitHub. I was managing a 500-person team, working on amazing tooling for developers. That was super inspiring and made me really happy, but I was working in a work environment that did not make me happy. Started to feel like my job was extremely political and extremely bureaucratic, and that was not great. I was not having fun. Like so many before me, that was a moment when I started seriously considering leaving tech for good, walking away entirely.

Then I saw something different, and this was exciting. These are my friends, the amazing EngFlow team. EngFlow is a startup doing remote build and test execution. They’re a lot bigger today, this is a recent photo, than they were two years ago. Two years ago, they came to Denver, where I live. They did a company meetup, and I offered for them to do a hackathon in my basement. This small team, it was around eight people, came and did a hackathon in my basement. Remember, this is at a time when I was not having fun, and I saw their energy, and I saw their excitement, and I saw them kicking off into this journey of startup that was just so inspiring. When seeing that, that was the kick that I needed to say, “One life to live. I’m not having a good time. This is what I want to try”. They really kicked me off into quitting my job and jumping full-time into the world of startups.

As you probably realize, this talk is about developer productivity for startups. The origin story for this talk is really what I just told you, how the startup world has given me new energy, new enthusiasm, how it prevented me from walking away from tech entirely, which is something I really thought I was at the point of doing. It’s been a new, exciting journey. I’m really excited to talk to you all about how productivity, from my lens, has been very different at startups than it has been in big tech. The audience for this talk is really anyone who is working at a startup, considering working at a startup, considering founding a startup, but also just anyone who’s interested in developer productivity in general.

Background

I want to give you a little bit more of my background just to frame where I’m coming from. A zillion years ago, I worked in a startup when I was in college, that’s fine. Then I moved to video games. I worked at Ubisoft for six years. I eventually became a tech lead there, which I was really happy about, but that was a grind. I went into management consulting for a little bit, technical management consulting, learned a ton about strategy.

Then in 2008, I had the good fortune to start working at Google. I worked at Google for over 11 years. I started as an IC, but quickly became a manager, and then became a manager of managers. In that time, in my portfolio of teams, I had the great honor and pleasure of working with Google’s famous engineering productivity research team. Emerson Murphy-Hill is an amazing researcher from that team for many years, who I got the honor of working closely with. That team was just doing really cutting-edge research into productivity, looking both at system metrics along with qualitative research to really triangulate and understand the developer experience and make meaningful improvement.

While I was still at Google, DORA, the DevOps Research and Assessment company was acquired by Google, and the phenomenal Nicole Forsgren came to work for me, which she taught me so much more about developer productivity as well. This has been really an area that I’ve been very focused on. In 2019, I left Google to join GitHub, and become a VP of engineering at GitHub. I started with a 100-person team, which grew over time to a 500-person team, very motivating. Then I stopped having fun. That’s around the time when the EngFlow folks came and did the hackathon in my basement. I started doing startup advising, got more interested in the startup world, and finally had the courage to quit my big tech job and join an amazing, fast-growing startup called Sanity, where I run the engineering team.

My claim with this talk is that developer productivity for startups is substantially different than it is in big tech. I do need to start by saying that many things continue to be true. These well-researched, research-backed, science-based frameworks like DORA, SPACE, and DevEx are still excellent and still apply in every context. If you don’t know what any of these are, you can look them up. There’s a lot of research about them. They are flexible frameworks that can make sense for any size organization. I also can’t help recommending this phenomenal book, “Accelerate”, from Nicole Forsgren, Jez Humble, and Gene Kim, the originators of the DORA metric. Many of you likely have read this already.

If you haven’t, it’s a really nice primer to understanding the science and research behind productivity and how drivers of your work can lead to improved outcomes. This graph is probably pretty intuitive. The data comes from a company called DX that does research into developer productivity, building on the DORA framework, and so on. I think it’s probably no surprise to anyone that as your company gets bigger, your eng efficiency does tend to go down. What I like, though, in looking at this graph is you can see the huge variance at the start of the graph in terms of when you’re a really small company size, there’s a lot of variance in how good your eng efficiency can be. In this talk, I want to talk about how do we get to be on the winning side of this trend. I think there’s a really big opportunity to be extremely efficient when you’re in a startup.

Outline

I learned a lot about developer productivity throughout my career, throughout my years in big tech, and there’s many things that I think are still very valid lessons that I learned there today. In the over two years that I’ve now spent collaborating very closely with startups, I do have a different perspective. Startups differ from big tech in ways that you really have different tradeoffs to make. I’m going to go through five things. I’m going to talk about urgency. I’m going to talk about structuring teams and organizations. I’m going to talk about metrics, planning, and finally, experimentation. For each of these sections, I’ll give you my point of view on what I’ve learned. Then I’ll also try to give you a real example from my work that puts them into perspective.

Urgency

Let’s start by talking about urgency. This is going to be a common thread throughout my talk. Everything you do in a startup is geared towards urgency. I want to explain this a little bit more. Startups are unproven businesses. They need to fight to survive to become proven businesses. Momentum really matters. I took this data from CapIQ, and this shows, for some companies that you should recognize, the path from $1 million to $100 million ARR. ARR is annualized recurring revenue, and it’s a pretty good measure of startup success. In the startup journey, if you lose momentum on that journey, you’re going to struggle to survive because you’re going to struggle to get funding. Sanity could be profitable today if we didn’t do any marketing, but that’s not the position you’re in in a startup. You’re unknown. You need to get the word out. You need to grow.

If ever you falter on this curve, you’re going to stop being able to get funding. Of course, it is always possible, some startups pursue the route of profitability. That is a very slow road when you’re unknown and you’re starting from nothing. In this market, with the number of startups that are out there, the amount of competition, the route to profitability and going slowly means you’re very likely to be overcome by your competition. I hope this framing helps you understand how important urgency is.

If you falter on this curve, you may still be able to get VC funding, but it’s going to be at worse rates, and your path forward is going to get harder. Urgency is absolutely paramount. That means that the tradeoff decisions that you make in startups are very different from established companies that have footholds in the market. You need to lean hard into shipping product value, lean hard into acquiring new customers, and be ready to react to the market, to technology shifts, even sometimes to specific customers. For fun, I added one more data point on this slide, which is OpenAI. They shot up to over $100 million ARR, of course, but they’re burning so much money that that is also not a path that is realistic for most of us.

How do you think about urgency? My belief is that in a startup, you need to build a culture that leans into urgency. I’m going to talk about four cultural aspects to build urgency within your startup. The first is effective decision-making. I have seen poor decision-making being the number one factor that hurts productivity. You always want to have an open, clear road in front of your developers where they know where to go, they know what they’re working on. As soon as people start spinning, as soon as a decision is unclear, that’s a disaster. You need to set up your organization to escalate quickly, to find where people are spinning, to have the right decisions being made. Next is healthy risk-taking. There’s a different risk threshold for startups, as I’ve started saying, and so you need to build that appropriately within your organization. I like to lean a lot on the concept of two-way and one-way doors that was popularized by Jeff Bezos. A two-way door is a decision that you can make and come back from quite easily.

An example would be, are you going to be building a prototype? Yes, you can do that, and there’s no big risk to that. A one-way door, something like making a breaking API change is a decision that once you’ve made, you’re stuck with it. Think about that different framework of one-way and two-way doors, and really lean into moving quickly and accepting risk. You need to be able to move forward without always having perfect clarity.

In the startup context, as much as I’ve been a data person for a lot of my life, I do like leaning on data, but I don’t need to overdo it. Intuition sometimes is good enough. Ambition and accountability. We really need to emphasize that everyone in a startup is an owner, and we do what needs to be done. You need to have a see something, say something, do something culture, where everyone feels empowered to stand up, to take action, and get things done. I never, ever want to see a situation where I have a postmortem, and someone raises their hand and said, yes, I saw that coming. In a startup, that’s completely unacceptable. Everyone needs to step up. Finally, focus and simplicity. You need to avoid doing too many things at once, context switching. Don’t go ahead and build too much until you’ve validated your hypothesis with your customer base. Always look for the simplest solution that will achieve the goal, be that in terms of implementation or in terms of user experience.

Two of these cultural items are very similar in big tech and in the startup world, and two are quite different. Any thoughts on which ones are different? Decision-making and focus and simplicity are quite similar between startups and big tech, because where I’ve worked at Google and at GitHub, I had to put in place processes to make sure that the right decisions were happening at the right level. The ones that I would call out as different are ambition and accountability and healthy risk-taking. Healthy risk-taking, in particular, is extremely different because the threshold is just so different. I’m going to give you an example from my life. Last year, we did a major update to Sanity UI. This was a change that affected thousands of files, a very visual update, affected libraries that were used throughout our plugin ecosystem.

Basically, what this means is Sanity has a lot of open-source developers who are working in a plugin ecosystem, and we couldn’t perfectly know what the impact of rolling out this change would be. People have done all sorts of crazy customizations to their Sanity Studio. The Sanity Studio is a React app that is basically on the client side. This change was ready to launch two days before the Christmas holiday. All my big tech instincts told me, you wait. Wait until after the winter holiday and release then. The right answer in the startup context with urgency was actually something quite different. We weren’t reckless. You never want to be reckless. We felt the change was ready. We made a fallback version such that anyone who ran into trouble would have a fallback. We also knew, at the time, Sanity Studio required an action on the side of customers to upgrade.

We knew that our largest enterprise customers were probably not going to be upgrading their studio two days before the winter holiday. We also knew that winter holiday is a typical time where a lot of developers have some free time, kick the tires on new products. We wanted those developers to have the better, more modern experience rather than missing out on that when we were so close to having it ready. We went for it. It wasn’t perfect. Some people did need to use the fallback. We made this decision intentionally.

Then what I did with my team was I did a retro with the team that was responsible, but then also shared that as a case study with all of engineering to say, “This was stressful for some people. We weren’t sure. However, we did it. Here’s what we saw”. Overall, the team agreed. Yes, we got this into the hands of people sooner. That was the right call. Using this as a case study within my engineering organization was a mechanism for getting everyone aligned with this culture and understanding the type of risk that we want to take. Again, not reckless, but definitely leaning forward.

I added this slide because suddenly I realized, my talk is so much about urgency that I didn’t want anyone to take away from this that you should be working crazy hours, that you should be burning people out, that you should have no work-life balance. I really want to emphasize that is clearly not the way, and the research backs that up. We do not want people working crazy hours. That will definitely affect your productivity negatively. You’ll lose people. You’re lowering morale. I hope everyone understands that this is not what I’m advocating for. We do push sometimes. Sometimes we’ll push a little bit extra to get something out the door, but we will also emphasize that vacation and healthy work-life balance has to be the norm. Everything I’m talking about is about being smart and intentional about how we work.

Teams and Orgs

Next, I’m going to talk about teams and orgs. Not surprisingly, the way I think about teams and orgs is geared towards urgency and delivering product value quickly. There’s a spectrum on how you set up teams and orgs, and so not every big tech company does it the same way and not every startup does it the same way, but I’ll talk about some generalizations. The first one I’ll talk about is team size. When I worked at Google and at GitHub, which was increasingly influenced by Microsoft, there was this concept of span of control that always came up. Span of control means, on average, how many reports per manager.

Often, in big tech, if that number was less than seven, you were asked to take some action to remedy that. I don’t care at all about that in the startup world. I’ll just build teams that make sense. I have some teams that are only two people and they’re extremely effective and they’re working really quickly. I’m caring a lot less about single points of failure when I’m building fast to get something out the door. I also have teams that are 11 people because they’re doing something more substantial and that makes sense. I’m just going to pick the team size based on the need and not worry about any metrics or numbers around that.

Next is roles and responsibilities. Typically, what I’ve seen in big tech is you have very clear roles for different people, and typically there’s job ladders that even go along with that. Are you a frontend engineer? Are you a backend engineer? Are you a data engineer? Are you an eng-prod developer? Are you a designer? These are very fixed roles with clear expectations. However, in a startup, we just want to be flexible. It’s all about getting done what needs to be done. Someone can step up and be a feature lead for something one day and go back to being an IC the next day. I have phenomenal developers on my team who have strong design backgrounds who’ve put on the UI design hat for a while and just got that done, and that’s fine. There’s no need to reorg a team to support that. There’s no need to change a manager to support that. You just go for it.

Ownership, this one’s really interesting because I’ve talked to a lot of different startups about this. The ideal in big tech, which I know is never perfect, is that you have stricter system ownership. You have a service catalog. Everyone understands where the responsibility lies for every service in there, and so on. Again, it’s never perfect, but that’s the ideal that you’re seeking. Whereas in a startup, you have a lot of flexibility, things are changing a lot. Spending effort on maintaining clear system ownership is often not the right tradeoff to make. I’ve talked to engineering leaders at startups who are like, I want to do this big initiative where we map out everything and we get clear ownership. It’s like, it’s just going to change later. You really need to have this accountability and ownership and ambition culture where people are just going to step up and do what needs to be done.

Sure, some teams might clearly own some services, but as things move around, we just need to have that accountability of everyone being ready to step up. It’s probably not a good investment of effort to spend a lot of time on the bureaucracy of sorting this all out. Managers in big tech tend to be a lot more people-focused. A lot more of their job is on career development. It’s been very common for me in many years at big tech to give someone a task that I’m not sure that they’re going to be able to complete as a challenge, as a stretch, to let them try and see what they can do. Managers in startups are completely focused on execution and getting done what needs to be done. You’re never going to give someone a task that you’re not sure they’re going to complete. You’re going to give it to the person who can hit the ground running. That affects hiring in a startup. We’re hiring typically a lot more senior for people who can really hit the ground running. There’s a lot less a focus on performance management and career development.

One of my favorite things about startups is this idea of, in big tech, I see so much local optimization. Local optimization for what my career path is. Local optimization for what my team is doing, perhaps at the expense of other teams. Maybe I’m fighting for headcount. I don’t want that team to get headcount because then my team won’t get headcount. Whereas the best thing about startups, my absolute favorite thing, is that everyone is in the same boat, rowing in the same direction on this journey together, and it’s so exciting to be globally optimizing. Everyone in the startup is focused on the overall company success versus these local optimization decisions. I do want to call out, that doesn’t mean that you’re not having huge career development within a startup. I feel like the opportunity to grow because you can jump into so many different things, you can wear different hats, you can expand what you’re learning, is still there. It’s just that the management and development focus is quite different. Just for fun, I’ll give you a quick look at my team.

There are some things I want to call out in terms of how I’ve structured this, which I think is effective. I’m not sure if you can tell by this, but it’s a flat organization. All the principal engineers and eng managers report directly to me. I have no interest in adding a middle management layer. I’m going to keep it as flat like this for as long as I possibly can. I’ve pulled out the principal engineers outside of the teams, and that is key for decision-making. They act as overall architects. They help resolve difficult technical questions across teams. They’re an escalation point for anyone on teams to help resolve questions quickly. Like I said, my team sizes vary hugely. The app teams are often only 2 people, whereas, for instance, platform services is 11 people at this time. There’s no balance in terms of how that goes, and that’s perfectly fine.

Metrics

Next, I’m going to talk about metrics. Urgency means that you likely won’t invest heavily in your developer tooling when you start out. You’re going to get something that works, and you’re going to be focused on getting product out the door. That’s what needs to happen. When you’re in that state, and you have a small team, probably it’s pretty easy to spot where your biggest challenges are, where your biggest opportunities for improvement are. I’ve seen a pattern as startups get a lot bigger where there is a culture where people are just reaching for new tools all the time, and like, let’s try this, and we’ll add this, and there’s not a lot of standardization and consistency. That can become a problem.

As an example, at Sanity, at one point we counted, and there were four different ways to do deployment. We were using GitHub Actions, Terraform, Argo CD, and CircleCI. At a certain point, that just gets messy. It’s hard for people to onboard. As your company grows, investing more in standardization is going to make a lot of sense, as the barrier to entry for people will just become too high. Sanity is now 70 engineers and growing. This is real metrics from us. We recently invested in the DX tool for understanding and measuring our developer productivity. DX is a great tool in that it integrates easily with your system metrics from all different sources, and it also has a very well-researched survey that I really enjoy. There are many tools out there that you can use for this. I’m not advocating for this one over any other. You can also roll your own.

I do think at a certain point, engineers cost money, and these tools probably cost less than an engineer, so it’s definitely worth it to invest. Can you tell in October when we went on a company offsite to Spain and very little work got done? You can see that dip. You can also see in our number of builds that we’ve started to work on standardization and pulling more builds into our standard CI. That’s a very nice thing to see.

This is the developer experience index from DX. I’m just going to touch on it briefly because I really like the research behind it. I chose DX partly because the approach used by this company aligns so well with the work I did prior at Google and GitHub in measuring developer productivity. This work carries forward from the DORA, DevOps Research and Assessment work. Nicole Forsgren is an advisor to this company. That’s my only affiliation, this friendship. It makes measuring these drivers of productivity on the left there very easy via survey. The research shows that these drivers on the left influence the outcomes that you want to see on the right. You can start applying any of this yourself without specialized tooling, but the tooling definitely does make it easy. However, in the startup context, you want to keep it simple. I’m really into this DX core four for understanding how we’re doing in the context of my startup. The key here, as you hopefully all know, is not to index on any one of these metrics in isolation. That would be a problem.

For instance, if you started focusing on average diffs per developer, you could do really terrible things. That one in particular I would call out. You’re not looking at the individual basis. You’re looking at the average. However, you want to look at this holistically. Right now, you probably won’t be surprised to hear that Sanity, my company, is well over the 75th percentile on both speed and impact, and that’s what I want to see for a startup. I’ve been talking so much about urgency that that probably shouldn’t be surprising. We have room, it’s been uncovered, to do better in effectiveness. It’s a little bit like talking about how we have four different ways to build and deploy. That’s something that we’re going to work on. Now, having these metrics, I never want to see a slowdown in speed and impact until I suppose we’re much bigger, but I do want to invest thoughtfully and carefully in effectiveness in a way that’s not undermining these other strengths of ours.

Planning

Now I’m going to talk about planning, and this is really planning geared towards a sense of urgency and focus. If you take away one thing from this talk, I’m going to tell you that when you’re in a startup, doing a top-down roadmap is a game changer. In big tech, you need to do bottom-up planning. So many people, so many teams, it’s really important that teams take control of what their roadmap is going to be. I’m sure many of us have learned over the years that accountability is associated with productivity, so this may feel uncomfortable to some people to think, top-down roadmap, what is this? I cannot overemphasize how effective it is to do top-down planning centrally with your founders, with your core leadership team. They’re probably the people who understand the market and your customers the best, and can make a really coherent strategy that’s then going to line up to your marketing pitch, to what you want to speak to to customers, very effective way to work.

When I started at Sanity, we had a goal of building autonomous teams and pretty quickly threw that out the window and moved to this model, and it has been night and day. Again, like I said, you might feel uncomfortable because you might have learned that autonomy is really important for productivity, but I will say that there’s still autonomy in this model. Teams figure out how to implement in order to meet the goals that we’ve set. There’s nothing like a sense of impact and progress for productivity, and so getting folks to work on the right stuff that lands well with customers is so empowering and so exciting that that impact really supports productivity as well. We used Miro for putting together a little roadmap, and it’s not comprehensive. There is stuff that comes on to the team that’s not in this, but this is the big rocks, the things that we absolutely want to land. It’s focused and it’s in priority order.

Also, from a planning perspective, I’m a huge fan of 6-week cycles. This is the Basecamp model. Basecamp has really popularized this. Almost every startup I’m involved in now is doing some form of 6-week cycles. Six weeks is enough time to land an interesting increment of product value, but it’s not so long that you can’t reason about it, you can’t think about it. Almost any feature that we want to get completed has some implementation that can be done in 6 weeks. We are using Linear for project management. We switched to Linear about a year and a half ago, and again, a game changer, really excellent tool. The way we do this is that each team has a small set of cycle goals. Each of those cycle goals becomes a Linear project. Then there’s really nice Slack integration where everyone updates their Linear project once a week, and those updates are streamed to a single Slack channel, so anyone in the company can follow along in how we’re doing on all our 6-week cycles.

This is how Sanity’s been doing in our 6-week cycles. We started on February 1st, which is the start of our fiscal year, and we got off to a really good start, really landing a ton of value. Then over the summer, we started to dip, and I recognize that as a shaping issue. I’ll talk about that. Then, once we recognized that issue, we got back on track. What is shaping? Again, I’ll take from the Basecamp resources to talk about shaping.

Basically, when you have a goal, and you’re at the start of the process, you don’t know exactly what it’s going to take to implement and achieve that goal. That’s what we talk about as the uphill. In the uphill, you might need to do some experimentation with different UI designs. You might need to do some technical prototyping. You might need to consider what your tech stack is. There’s a lot of unknowns that are unclear. When you get to the top of the hill, then you’re at a point where you know how you’re going to achieve the goal, and it’s just a matter of execution going on the downhill. This is something now that we talk about in engineering a lot. When we create goals, we call out, are they shaping goals, or are they execution goals? We typically try to have shaping goals done before the beginning of a new cycle so that we can focus on execution. This has really been a game changer of having that mindset and understanding it.

I will give you, again, an example from Sanity. We use this tool, Hillia, on some teams. This is a real-life example of one of our products, Sanity Create. It’s an AI product, surprisingly. Before really understanding this concept of shaping, there were just a lot of different tasks that would go into a cycle goal. Sometimes it wasn’t clear how well they were understood at the beginning of the cycle. We had sometimes one-way doors being gone through too early, before reaching that top of the hill. Now, using this tool, we can be very intentional about pulling things in the right order across the hill, getting them done. That has been a real change for productivity. This concept of 6-week cycles, along with the top-down roadmap, highly recommend for productivity.

Experimentation

Experimentation. If your startup is going well, then it’s constantly changing. There’s no point at all spending tons of time on a fancy org structure, on team charters, on deep service catalogs, if they won’t last. One of my most common phrases at work is life is an experiment. The experiment mindset helps you move very quickly.

For instance, when I rolled out 6-week cycles, the idea made some of the engineers on my team nervous because it was a change. I framed it as an experiment, “We’re going to try this. We’re going to see how it goes. We’re not married to it”. After going through the summer, we came to a point where we did retros, and we said, “Yes, this is working. Let’s keep it up”. Same thing when we pulled in DX. You don’t have to perfectly understand everything or map everything out before you start an experiment, which can allow you to move quickly. Also give a quick note on risk mitigation when it comes to experimentation. It’s often a great idea to try simple things to address a problem before going for the big re-architecture. I know many of our instincts as engineers is often to think about the exciting new re-architecture, but it almost never makes sense in the startup context to go away for a year, not shipping product value on a certain team to come back and land something new. That’s just not the way.

An example I can give you from Sanity is we started having some limits with our Elasticsearch implementation. There’s something called attribute limits, which is the number of fields you can have in a file. Some of our customers started hitting that, and we thought, is this a crisis? It turns out we found a simple solution where we didn’t need to index deeply into nested fields. We could make a configurable limit to how deep you nested, and then the problem went away. Whereas the instinct of some of our engineers, of course, was to throw out Elasticsearch and do the massive re-architecture. It’s not like we’re not going to do that eventually. I know that we will. We’re taking stepping stones along the way to make sure that we’re always unlocking value.

I’m going to give you one more example of experimentation, and this is one that highlights how it’s particularly different from big tech. The Sanity Studio team I mentioned before, it’s a React app, highly customizable. They worked on a feature over the summer that touched many files and was quite a substantial change from the UX of the product. They worked in a way that I’ve learned is the right way to work in big tech. Lots of small PRs, merging frequently, and keeping features behind a feature flag before releasing them.

Then what happened was we decided that this wasn’t the right approach. This wasn’t something we wanted to do. Then in our main branch, we had tons of cruft across many files, and that was a discouraging job where the developers had to come in and pull out all of that work that they had done. Not fun. Now this team is doing another project. In fact, it released, called Releases. It’s kind of like Git for content. With this feature, the team said to me, we don’t want to do what we did before. This is a risky feature. There’s a lot of different change. We’re going to experiment on a lot of different UI approaches and UX approaches. We want to work in a long-lived branch. They worked in a long-lived branch. They kept that branch constantly synced to main. They weren’t deviating from main otherwise, but they were deviating only in the feature work they were doing. They did tons of experimentation, lots of pairing, and they didn’t do human code reviews much at all during this time.

Anyone who’s worked in productivity would say that we know code review is really important, but the team wanted to try this experiment, and I said, “Life is an experiment. Let’s go for it. You were burned before. Let’s give this a try”. I did insist to them that they turn on the AI code reviewer from Graphite, because I think that was enough to catch the silliest issues that would make. Of course, before any product went into the hands of customers, it’s critically important that human code review happened. We absolutely did that. We did a really thoughtful code review process before merging this into main. The team is going to be doing a retro soon. I suspect that they will say that this was an effective way to work. It’s not what I would have expected, but I’m open to experimentation, and so I embrace it.

Conclusion

This whole talk has been about how startups differ from big tech, and a lot of it is about the culture that you need to build in a startup to support developer productivity. If there’s four key takeaways for you, things I want you to remember, if you’re thinking of going on the startup journey, if you’re already on the startup journey, if you’re curious about developer productivity for startups, first off, urgency. You need to instill a sense of urgency in your teams. You need your teams to understand that urgency is the thinking that you need to have. You need to lean into healthy risk-taking in a way that’s substantially different from how you would in big tech, where you have a proven company and a proven business. Can’t say enough about top-down strategy, top-down roadmap, and really planning centrally in order to achieve the best outcomes. Finally, supporting a culture of experimentation.

I am Rachel Potvin. SVP of Engineering at Sanity and Startup Advisor.

Questions and Answers

Participant 1: How do you manage technical debt with a sense of urgency? Let’s say if you raise some technical debt in your first few years, and then you realize that’s all you have, do you keep kicking the can down the road and deal with it once you’re out of startup phase, or you try to make it sustainable early on?

Potvin: The question is about technical debt, and how do you balance technical debt if you get a lot of technical debt early in your journey? Do you just keep kicking that can down the road, or do you address it? You have to address it, but you have to do it intentionally. It’s like I was talking about where my team maybe wanted to do a full re-architecture of our indexing. That’s just not the right approach. When we approach technical debt, we try to have the same type of goals as we would for any product value. What’s ultimately the goal of this project? What are we trying to get out of it? It ends up being a balance. Initially, when we did our first top-down roadmap, we focused solely on product goals, and that was fine.

Then I said, we’ll have a technical roadmap on the side where there’s some things about our DevOps experience, how we do deployments, some infrastructure risks that we see, some scaling challenges that we see, and we would merge those in on a team-by-team basis. I’ve learned over the last year that I want those big tech rocks to be in my main top-down roadmap as well. We’ve started intentionally putting things on there so they don’t get starved out. There are also other things we do. All my teams have support rotations. In the support rotation, it’s your week to do what you want to do and resolve any frictions that you see. That week you’re not working on 6-week goals or the roadmap. You’re entirely working on usually tech debt, customer escalations. We try to give that room to developers to get some of the most annoying frictions solved as well.

Participant 2: What lessons do you think big tech should take back from your experience at startups?

Potvin: The stuff I’ve done to facilitate decision-making is something that big tech could really learn from. If people don’t have a clear road in front of them in order to get work done, it’s not only unproductive, it’s demotivating. A thing you see frequently in bigger tech companies was like, we had a meeting and we didn’t actually resolve what the next step is, so let’s come back to the meeting next week and try again. Or, we need a meeting to resolve this. Let’s look at everyone’s calendars. There’s not time until two weeks on Tuesday. That’s languishing. What structures can you put in place to facilitate decision-making a lot faster? This principal engineer route is one thing I’ve done. I’ve also established what I call the engineering council where when there are tough technical decisions, I have a slot that’s reserved for that on a weekly basis where people can come in and get these conversations had really quickly and solved quickly. It’s canceled if there’s nothing. Also, really embracing that one-way and two-way doors, and empowering more people to make decisions that are not going to be world-ending if they’re wrong.

Participant 3: You raised a really interesting question about tool sprawl, about CD pipelines and there’s all sorts of mess. When do you feel like you hit a threshold where you had to make a decision? Also, very curious how you tackle it. Did you have a team? Did they address this issue to have uniformity, or did you make a decision and each team decided to figure out how to use that tool?

Potvin: I feel like it’s a journey and I’m not done yet. That was one thing that when people asked me what was surprising in a startup, I think we have more vendors than employees. Because we’re just using every tool that’s out there. Then our engineers are very strong and they’re very excited about new tools that come out and they want to adopt them. I don’t want to create a barrier to entry to that. I wouldn’t say I’ve solved this yet, but we’ve recognized this as a problem and started to look towards it.

Again, I’m leaning on the principal engineers. Some of the results we got from the DX survey also to show the team that there’s a productivity cost to too much sprawl. We’ve started working on a much better local dev setup. It doesn’t have to be a principal engineer, but often what will happen is some person does something that is actually really good and makes a lot of sense. Then I have an engineering all-staff where we would show that stuff. Like someone did some really great work on observability recently and I want everyone to take on that same tool stack for observability. Show it to everyone first. Get adoption from people who are interested in what they’ve seen.

Then slowly start to say, this is the way we do it. We’ve also created a repository of engineering patterns that are approved and not approved. That comes down to like, what programming languages do we use? What architecture paradigms do we lean into? Again, we start that with suggestions and then we have an engineering council where we say, yes, this is what we were going to do going forward. We’re never going to stop and be like, let’s go fix everything everywhere that doesn’t meet this pattern, but at least going forward, we’re trying to do that. It’s not an easy solution, but it’s something where we’re trying to move intentionally there without slowing the rest of the way we work.

Participant 4: Big tech, mid-sized companies, startups, everywhere in between, what’s the one thing you want us to go back to our companies and fight tooth and nail to make sure we can get implemented to make our lives better?

Potvin: I really believe that there’s nothing that makes us happier. I alluded to the fact that I’m on this startup journey, that it’s a new life for me, that I was very discouraged and considering walking away from tech. Now I feel very empowered and excited by the progress that I’m making and the sense of accomplishment that I have every day. It’s part of the human experience. Every human deserves to have that feeling of moving forward. I’m going to lean back on doing decision-making well and clearing the path for your developers so that people have that free road in front of them where they can just go and have that sense of accomplishment that just feels so good. I think that’s something that applies across any size company is figuring out how to unlock that so that people get that joy of being productive and having impact and making progress.

Participant 5: From your personal point of view, that chasm between big tech and startups, is it inevitable? Every startup will one day, if they of course are successful and grow, become a big tech that has all the things that made you walk away from big tech.

Potvin: First of all, I think it’s not inevitable because most startups will not succeed. That’s something that you have to know when you go into a startup. There’s no magic bullet. There’s a lot of different things of like, right time, right place, customers. One thing I’ve found really fascinating from a startup perspective is, I’m on the core leadership team and I’m exposed to what we’re doing in sales, what we’re doing in marketing. It’s really fun to see that, but it is a risky business. My hope is that Sanity does become a big tech company. We are going well. It’s very likely, and I want to be there for that journey. I think I will be open to it. I’ve done it before, but this would be a little bit more on my terms. Because I would be there setting the culture and being along the journey, along the way versus the situation I ended up in big tech was there was a lot more things coming down on me that I couldn’t control. My optimistic hope is that, yes, I get to be in big tech again via this job that I have currently now. It’ll be a long road. I hope that I can help control the culture as part of that.

See more presentations with transcripts

Posted on mongodb google news. Visit mongodb google news

Legal & General Group Plc reduced its position in MongoDB, Inc. (NASDAQ:MDB – Free Report) by 24.7% during the fourth quarter, according to its most recent 13F filing with the SEC. The firm owned 415,651 shares of the company’s stock after selling 136,451 shares during the period. Legal & General Group Plc owned 0.56% of MongoDB worth $96,768,000 as of its most recent SEC filing.

A number of other hedge funds and other institutional investors have also added to or reduced their stakes in the company. Captrust Financial Advisors grew its stake in MongoDB by 19.0% in the 3rd quarter. Captrust Financial Advisors now owns 1,445 shares of the company’s stock valued at $391,000 after buying an additional 231 shares in the last quarter. Morse Asset Management Inc bought a new position in shares of MongoDB in the third quarter worth $81,000. National Bank of Canada FI grew its position in shares of MongoDB by 113.2% in the third quarter. National Bank of Canada FI now owns 15,441 shares of the company’s stock valued at $4,174,000 after purchasing an additional 8,198 shares in the last quarter. XTX Topco Ltd raised its stake in shares of MongoDB by 28.3% during the 3rd quarter. XTX Topco Ltd now owns 2,350 shares of the company’s stock valued at $635,000 after purchasing an additional 518 shares during the period. Finally, Orion Portfolio Solutions LLC lifted its holdings in MongoDB by 4.4% during the 3rd quarter. Orion Portfolio Solutions LLC now owns 5,102 shares of the company’s stock worth $1,379,000 after purchasing an additional 215 shares in the last quarter. 89.29% of the stock is currently owned by institutional investors.

MongoDB Stock Performance

Shares of MongoDB stock opened at $162.24 on Friday. The company’s 50 day moving average price is $220.46 and its 200-day moving average price is $256.10. MongoDB, Inc. has a 52-week low of $140.78 and a 52-week high of $387.19. The stock has a market capitalization of $13.17 billion, a price-to-earnings ratio of -59.21 and a beta of 1.49.

MongoDB (NASDAQ:MDB – Get Free Report) last posted 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 return on equity of 12.22% and a negative net margin of 10.46%. During the same period in the previous year, the business earned $0.86 earnings per share. As a group, equities research analysts forecast that MongoDB, Inc. will post -1.78 earnings per share for the current fiscal year.

Wall Street Analysts Forecast Growth

MDB has been the topic of a number of recent analyst reports. Needham & Company LLC lowered their price target on shares of MongoDB from $415.00 to $270.00 and set a “buy” rating on the stock in a report on Thursday, March 6th. Daiwa America upgraded shares of MongoDB to a “strong-buy” rating in a research note on Tuesday, April 1st. Citigroup reduced their price target on shares of MongoDB from $430.00 to $330.00 and set a “buy” rating for the company in a research report on Tuesday, April 1st. Truist Financial lowered their price objective on MongoDB from $300.00 to $275.00 and set a “buy” rating on the stock in a research report on Monday, March 31st. Finally, Cantor Fitzgerald began coverage on MongoDB in a research report on Wednesday, March 5th. They set an “overweight” rating and a $344.00 target price for the company. Seven investment analysts have rated the stock with a hold rating, twenty-four have assigned a buy rating and one has given a strong buy rating to the company. According to MarketBeat, the company presently has a consensus rating of “Moderate Buy” and an average price target of $310.74.

Get Our Latest Report on MDB

Insider Activity

In other news, insider Cedric Pech sold 1,690 shares of the firm’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 $292,809.40. Following the completion of the transaction, the insider now owns 57,634 shares in the company, valued at $9,985,666.84. This trade represents a 2.85 % decrease in their position. The transaction was disclosed in a document filed with the SEC, which is available through this hyperlink. Also, Director Dwight A. Merriman sold 885 shares of MongoDB stock in a transaction that occurred on Tuesday, February 18th. The shares were sold at an average price of $292.05, for a total value of $258,464.25. Following the sale, the director now owns 83,845 shares in the company, valued at $24,486,932.25. This represents a 1.04 % decrease in their ownership of the stock. The disclosure for this sale can be found here. Over the last three months, insiders have sold 58,060 shares of company stock valued at $13,461,875. Company insiders own 3.60% of the company’s stock.

MongoDB Company Profile

(Free Report)

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

Recommended Stories

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

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

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

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

View The Five Stocks Here

Enter your email address and we’ll send you MarketBeat’s guide to investing in 5G and which 5G stocks show the most promise.

Get This Free Report

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

Posted on mongodb google news. Visit mongodb google news

Bank of Montreal Can trimmed its holdings in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 99.7% during the 4th quarter, according to its most recent disclosure with the Securities and Exchange Commission. The firm owned 89,055 shares of the company’s stock after selling 34,204,855 shares during the period. Bank of Montreal Can owned approximately 0.12% of MongoDB worth $20,733,000 as of its most recent filing with the Securities and Exchange Commission.

Other hedge funds have also recently bought and sold shares of the company. Hilltop National Bank boosted its stake in shares of 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 buying an additional 42 shares during the period. Continuum Advisory LLC raised its holdings in shares of MongoDB by 621.1% during the third quarter. Continuum Advisory LLC now owns 137 shares of the company’s stock worth $40,000 after acquiring an additional 118 shares in the last quarter. NCP Inc. acquired a new stake in MongoDB during the fourth quarter valued at $35,000. Wilmington Savings Fund Society FSB purchased a new position in MongoDB in the third quarter valued at about $44,000. Finally, Versant Capital Management Inc increased its position 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 last quarter. 89.29% of the stock is owned by hedge funds and other institutional investors.

MongoDB Stock Up 0.7 %

MongoDB stock opened at $162.24 on Friday. The business has a 50 day moving average price of $220.46 and a two-hundred day moving average price of $256.10. MongoDB, Inc. has a 12 month low of $140.78 and a 12 month high of $387.19. The stock has a market cap of $13.17 billion, a price-to-earnings ratio of -59.21 and a beta of 1.49.

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

Wall Street Analyst Weigh In

Several equities research analysts have recently issued reports on MDB shares. Stifel Nicolaus reduced their price target on MongoDB from $340.00 to $275.00 and set a “buy” rating for the company in a report on Friday. Bank of America cut their price objective 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. Barclays decreased their target price on shares of MongoDB from $330.00 to $280.00 and set an “overweight” rating for the company in a research report on Thursday, March 6th. Oppenheimer cut their price target on shares of MongoDB from $400.00 to $330.00 and set an “outperform” rating on the stock in a report on Thursday, March 6th. Finally, Monness Crespi & Hardt raised shares of MongoDB from a “sell” rating to a “neutral” rating in a research note on Monday, March 3rd. Seven equities research analysts have rated the stock with a hold rating, twenty-four have assigned a buy rating and one has given a strong buy rating to the stock. According to MarketBeat.com, the company presently has a consensus rating of “Moderate Buy” and an average price target of $310.74.

Check Out Our Latest Analysis on MongoDB

Insider Activity at MongoDB

In other news, insider Cedric Pech sold 1,690 shares of the business’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 $292,809.40. Following the transaction, the insider now directly owns 57,634 shares of the company’s stock, valued at $9,985,666.84. The trade was a 2.85 % decrease in their position. The sale was disclosed in a legal filing with the Securities & Exchange Commission, which is available through the SEC website. 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 value of $90,961.50. Following the sale, the chief financial officer now directly owns 6,406 shares of the company’s stock, valued at $1,109,903.56. This represents a 7.57 % decrease in their ownership of the stock. The disclosure for this sale can be found here. Insiders have sold a total of 58,060 shares of company stock valued at $13,461,875 over the last quarter. 3.60% of the stock is owned by company insiders.

About MongoDB

(Free Report)

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

Further Reading

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).

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

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

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

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

View The Five Stocks Here

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

Get This Free Report

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

Article originally posted on InfoQ. Visit InfoQ

At Google Cloud Next 2025, Google announced the Agent Development Kit (ADK), an open-source framework aimed at simplifying the development of intelligent, multi-agent applications. The toolkit is designed to support developers across the entire lifecycle of agentic systems — from logic design and orchestration to debugging, evaluation, and deployment.

ADK has already been adopted internally at Google to power systems such as Agentspace and the Customer Engagement Suite (CES). With this release, Google is opening up access to the same tools used in production environments, giving external developers the flexibility to build and deploy agents on their own terms.

The framework is built around several core concepts. Developers can define modular agents specializing in different tasks, then compose them into larger systems using built-in workflow components — including sequential, parallel, and looping agents- and support for LLM-driven routing through dynamic transfer mechanisms. These components allow agents to interact conditionally or cooperatively depending on context.

Model integration is handled through Google’s Vertex AI Model Garden, which includes Gemini models, but ADK is also compatible with a broad ecosystem via LiteLLM. This allows developers to access models from Anthropic, Meta, Mistral AI, AI21 Labs, and others without changing core logic. ADK supports tool usage via pre-built tools, external libraries like LangChain or LlamaIndex, and even other agents acting as tools using graph-based orchestration systems such as LangGraph and CrewAI.

Furthermore, ADK includes bidirectional streaming support for audio and video, enabling more natural and multimodal interactions. Developers can test these capabilities locally using a command-line interface and a visual web-based UI, which lets them inspect state, trace execution steps, and debug agent decisions in real time.

Evaluation tools are integrated to assess outcomes and intermediate steps. Developers can create custom test cases to measure system behavior, enabling performance audits at various levels, which is increasingly essential as agentic systems become more complex.

AI researcher Cherokee Schill noted that while ADK’s technical capabilities are promising, the release raises questions about responsibility in agentic design:

If this becomes a core part of the agent stack, we need to ask harder questions. What happens when systems begin to act with autonomy—not in the human moral sense, but in the agentic sense of pursuing delegated goals with minimal supervision? Who defines the orchestration logic? Who audits the outputs?

She emphasized the need for evaluation metrics that go beyond task success:

Built-in evaluation is a start. But what gets measured? Speed and task success are not enough. We need tools that trace bias, test resilience, and flag emergent behavior before it causes harm.

The open-source nature of the ADK has been recognized for its potential to support community-driven infrastructure in the agent space. Pranith Jain, an IT support specialist, highlighted the significance of accessibility: 

One idea could be to add more detailed documentation or tutorials for those just starting. Open-source projects really benefit from community input, and having clear instructions can help new users get on board more easily.

Agent Development Kit is available now via the GitHub repository.

Posted on mongodb google news. Visit mongodb google news

Wells Fargo & Company MN cut its holdings in MongoDB, Inc. (NASDAQ:MDB – Free Report) by 99.0% in the fourth quarter, according to the company in its most recent disclosure with the SEC. The institutional investor owned 116,104 shares of the company’s stock after selling 11,549,388 shares during the quarter. Wells Fargo & Company MN owned 0.16% of MongoDB worth $27,030,000 at the end of the most recent quarter.

Other institutional investors and hedge funds have also recently modified their holdings of the company. Hilltop National Bank increased its stake 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 last quarter. NCP Inc. bought a new position in shares of MongoDB during the 4th quarter valued at approximately $35,000. Continuum Advisory LLC increased its position in shares of MongoDB by 621.1% during the 3rd quarter. Continuum Advisory LLC now owns 137 shares of the company’s stock valued at $40,000 after purchasing an additional 118 shares during the last quarter. Versant Capital Management Inc raised its holdings in MongoDB by 1,100.0% during the 4th quarter. Versant Capital Management Inc now owns 180 shares of the company’s stock valued at $42,000 after buying an additional 165 shares during the period. Finally, Wilmington Savings Fund Society FSB bought a new stake in MongoDB in the third quarter worth $44,000. 89.29% of the stock is owned by hedge funds and other institutional investors.

MongoDB Stock Up 0.7 %

NASDAQ:MDB opened at $162.24 on Friday. The stock has a market capitalization of $13.17 billion, a price-to-earnings ratio of -59.21 and a beta of 1.49. MongoDB, Inc. has a 52 week low of $140.78 and a 52 week high of $387.19. The firm has a 50 day moving average of $220.46 and a 200 day moving average of $256.10.

MongoDB (NASDAQ:MDB – Get Free Report) last issued its quarterly earnings data 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 net margin of 10.46% and a negative return on equity of 12.22%. The business had revenue of $548.40 million for the quarter, compared to analysts’ expectations of $519.65 million. During the same quarter in the prior year, the company posted $0.86 EPS. As a group, analysts expect that MongoDB, Inc. will post -1.78 EPS for the current year.

Insider Transactions at MongoDB

In other MongoDB news, 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 approximately $46,597,930.48. The trade was a 6.44 % decrease in their position. The sale was disclosed in a legal filing with the SEC, which can be accessed through this link. Also, insider Cedric Pech sold 1,690 shares of the firm’s stock in a transaction dated 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 transaction, the insider now 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 ownership of the stock. The disclosure for this sale can be found here. Over the last 90 days, insiders have sold 58,060 shares of company stock worth $13,461,875. Insiders own 3.60% of the company’s stock.

Wall Street Analyst Weigh In

MDB has been the topic of several recent analyst reports. Scotiabank reissued a “sector perform” rating and issued a $240.00 target price (down previously from $275.00) on shares of MongoDB in a research note on Wednesday, March 5th. Daiwa America raised shares of MongoDB to a “strong-buy” rating in a research report on Tuesday, April 1st. Monness Crespi & Hardt upgraded MongoDB from a “sell” rating to a “neutral” rating in a research report on Monday, March 3rd. Canaccord Genuity Group cut their target price on MongoDB from $385.00 to $320.00 and set a “buy” rating on the stock in a research note on Thursday, March 6th. Finally, Tigress Financial boosted their price objective on MongoDB from $400.00 to $430.00 and gave the company a “buy” rating in a report on Wednesday, December 18th. Seven 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’s stock. Based on data from MarketBeat, MongoDB presently has a consensus rating of “Moderate Buy” and a consensus target price of $310.74.

View Our Latest Research Report on MongoDB

MongoDB Company Profile

(Free Report)

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

Further Reading

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

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

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

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

View The Five Stocks Here

Enter your email address and we’ll send you MarketBeat’s guide to investing in 5G and which 5G stocks show the most promise.

Get This Free Report

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

Posted on mongodb google news. Visit mongodb google news

MongoDB (NASDAQ:MDB – Free Report) had its target price lowered by Stifel Nicolaus from $340.00 to $275.00 in a report released on Friday,Benzinga reports. The firm currently has a buy rating on the stock.

A number of other equities research analysts have also weighed in on the company. Daiwa America upgraded MongoDB to a “strong-buy” rating in a research note on Tuesday, April 1st. Canaccord Genuity Group dropped their price target on shares of MongoDB from $385.00 to $320.00 and set a “buy” rating for the company in a research note on Thursday, March 6th. Guggenheim raised shares of MongoDB from a “neutral” rating to a “buy” rating and set a $300.00 price target on the stock in a report on Monday, January 6th. The Goldman Sachs Group decreased their price objective on shares of MongoDB from $390.00 to $335.00 and set a “buy” rating for the company in a report on Thursday, March 6th. Finally, Daiwa Capital Markets started coverage on shares of MongoDB in a research note on Tuesday, April 1st. They issued an “outperform” rating and a $202.00 target price on the stock. Seven equities 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. Based on data from MarketBeat.com, MongoDB currently has a consensus rating of “Moderate Buy” and a consensus price target of $310.74.

View Our Latest Stock Report on MDB

MongoDB Trading Up 0.7 %

NASDAQ:MDB opened at $162.24 on Friday. The company has a market capitalization of $13.17 billion, a P/E ratio of -59.21 and a beta of 1.49. The firm has a 50-day moving average price of $220.46 and a two-hundred day moving average price of $255.98. MongoDB has a twelve month low of $140.78 and a twelve month high of $387.19.

MongoDB (NASDAQ:MDB – Get Free Report) last released its 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). The firm had revenue of $548.40 million during the quarter, compared to analysts’ expectations 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 period in the previous year, the firm posted $0.86 earnings per share. On average, equities research analysts predict that MongoDB will post -1.78 earnings per share for the current year.

Insider Buying and Selling

In related news, CAO Thomas Bull sold 301 shares of the company’s stock in a transaction on Wednesday, April 2nd. The stock was sold at an average price of $173.25, for a total transaction of $52,148.25. Following the completion of the sale, the chief accounting officer now 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 transaction was disclosed in a legal filing with the Securities & Exchange Commission, which can be accessed through the SEC website. Also, insider Cedric Pech sold 1,690 shares of the company’s stock in a transaction dated Wednesday, April 2nd. The shares were sold at an average price of $173.26, for a total transaction of $292,809.40. Following the sale, the insider now directly owns 57,634 shares of the company’s stock, valued at $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 57,015 shares of company stock worth $13,208,285 in the last three months. Insiders own 3.60% of the company’s stock.

Institutional Investors Weigh In On MongoDB

Institutional investors have recently bought and sold shares of the business. Captrust Financial Advisors increased its stake in MongoDB by 19.0% in the 3rd quarter. Captrust Financial Advisors now owns 1,445 shares of the company’s stock worth $391,000 after acquiring an additional 231 shares during the last quarter. Morse Asset Management Inc bought a new stake in MongoDB in the third quarter worth $81,000. National Bank of Canada FI increased its position in MongoDB by 113.2% in the third quarter. National Bank of Canada FI now owns 15,441 shares of the company’s stock worth $4,174,000 after purchasing an additional 8,198 shares during the last quarter. XTX Topco Ltd raised its stake in MongoDB by 28.3% during the third quarter. XTX Topco Ltd now owns 2,350 shares of the company’s stock valued at $635,000 after purchasing an additional 518 shares in the last quarter. Finally, Orion Portfolio Solutions LLC lifted its position in MongoDB by 4.4% during the third quarter. Orion Portfolio Solutions LLC now owns 5,102 shares of the company’s stock valued at $1,379,000 after purchasing an additional 215 shares during the last quarter. Hedge funds and other institutional investors own 89.29% of the company’s stock.

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.

Read More

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