Month: January 2024

Posted on nosqlgooglealerts. Visit nosqlgooglealerts

According to IMARC Group, the global NoSQL market size reached US$ 9.5 Billion in 2023. Looking forward, IMARC Group expects the market to reach US$ 74.5 Billion by 2032, exhibiting a growth rate (CAGR) of 24.9% during 2024-2032.

The report has segmented the market by database type (key-value based database, document based database, column based database, graph based database), vertical (BFSI, healthcare, telecom, government, retail, and others), application (data storage, metadata store, cache memory, distributed data depository, e-commerce, mobile apps, web applications, data analytics, social networking, and others), and region.

Request a Free PDF Sample of the Report: https://www.imarcgroup.com/nosql-market/requestsample

Factors Affecting the Growth of the NoSQL Industry:

• Scalability and Flexibility Needs:

The rapid growth of data in the digital age necessitates highly scalable and flexible database solutions, which is a major factor driving the growth of the NoSQL market. NoSQL databases excel in handling vast amounts of unstructured or semi-structured data, thus making them well-suited for modern applications like social media platforms, e-commerce websites, and IoT devices. As businesses strive to accommodate growing data volumes and adapt to changing data structures, the scalability and flexibility offered by NoSQL databases are crucial for their success.

• Real-time Data Processing:

The rising demand for real-time data processing in the NoSQL market is driven by the need for businesses to make immediate and informed decisions based on up-to-the-minute information. Traditional databases often struggle to provide the speed and responsiveness required for modern applications and use cases, such as online gaming, financial trading, and recommendation engines. NoSQL databases excel in handling real-time data, enabling organizations to capture, process, and analyze data as it is generated. This capability is crucial in industries where split-second decision-making, dynamic monitoring, and rapid responses are essential, propelling the demand for NoSQL solutions that can deliver the agility and performance required for real-time applications.

• Variety of Data Types:

The diverse range of data types generated by modern applications, including text, images, videos, sensor data, and user-generated content, is a key driver of NoSQL adoption. NoSQL databases are designed to accommodate this variety, making them suitable for managing complex data structures. This factor is especially pertinent in industries like e-commerce, healthcare, and media, where the ability to handle and analyze diverse data types is vital for delivering personalized services, conducting research, and optimizing operations. As businesses recognize the importance of harnessing the value from this diverse data, NoSQL databases play a pivotal role in facilitating data management and analysis.

NoSQL Market Report Segmentation:

Breakup by Database Type:

• Key-Value Based Database
• Document Based Database
• Column Based Database
• Graph Based Database

Key-value based databases emerge as the largest database type segment in the NoSQL market due to their simplicity, high-performance characteristics, and suitability for various applications, including caching, session management, and real-time analytics, making them a popular choice for a wide range of industries.

Breakup by Vertical:

• BFSI
• Healthcare
• Telecom
• Government
• Retail
• Others

The telecom industry represents the largest vertical segment in the NoSQL market because it relies heavily on data-intensive applications such as customer relationship management (CRM), billing systems, and network management, where NoSQL databases excel in handling large volumes of customer data and real-time analytics.

Breakup by Application:

• Data Storage
• Metadata Store
• Cache Memory
• Distributed Data Depository
• e-Commerce
• Mobile Apps
• Web Applications
• Data Analytics
• Social Networking
• Others

Data analytics holds the largest application segment in the market due to the increasing demand for real-time and scalable data processing and analysis across industries, thus making NoSQL databases integral to modern data-driven decision-making and insights generation.

Breakup by Region:

• North America (United States, Canada)
• Asia Pacific (China, Japan, India, South Korea, Australia, Indonesia, Others)
• Europe (Germany, France, United Kingdom, Italy, Spain, Russia, Others)
• Latin America (Brazil, Mexico, Others)
• Middle East and Africa

North America leads the NoSQL market regionally due to the region’s concentration of technology-driven companies, startups, and enterprises that leverage NoSQL databases for their scalability and agility requirements. The presence of major technology hubs and data-centric industries in North America contributes to its dominant market position in the global NoSQL market.

Competitive Landscape With Key Players:

The competitive landscape of the NoSQL market has been studied in the report with the detailed profiles of the key players operating in the market.

Some of these key players include:

• Aerospike
• Amazon Web Services
• Apache Cassandra
• Basho Technologies
• Cisco Systems
• Couchbase, Inc
• Hypertable Inc.
• IBM
• MarkLogic
• Microsoft Corporation
• MongoDB Inc.
• Neo Technology Inc.
• Objectivity Inc.
• Oracle Corporation

Speak to an Analyst: https://www.imarcgroup.com/request?type=report&id=2040&flag=C

Global NoSQL Market Trends:

The growing preference for multi-model databases within the NoSQL realm offers the versatility to handle different data types and structures within a single database system which represents one of the key factors driving the growth of the NoSQL market across the globe. This trend enables businesses to streamline their data management processes and accommodate the diverse data generated by modern applications.

The market is also driven by the widespread adoption of cloud-based NoSQL databases due to the need for scalability, flexibility, and cost-efficiency. Cloud-native NoSQL solutions offer easy access to resources and the ability to scale dynamically, making them ideal for startups and enterprises alike. Additionally, the integration of NoSQL databases with artificial intelligence (AI) and machine learning (ML) technologies is gaining momentum. This integration enhances data analytics capabilities, enabling businesses to derive valuable insights from their data and improve decision-making processes.

Key Highlights of the Report:

• Market Performance (2018-2023)
• Market Outlook (2024-2032)
• Market Trends
• Market Drivers and Success Factors
• Impact of COVID-19
• Value Chain Analysis
• Comprehensive mapping of the competitive landscape

If you need specific information that is not currently within the scope of the report, we will provide it to you as a part of the customization.

Contact Us:
IMARC Group
134 N 4th St
Brooklyn, NY 11249, USA
Email: sales@imarcgroup.com
Americas: +1-631-791-1145 | Europe & Africa: +44-753-713-2163 | Asia: +91-120-433-0800

About Us
IMARC Group is a leading market research company that offers management strategy and market research worldwide. We partner with clients in all sectors and regions to identify their highest-value opportunities, address their most critical challenges, and transform their businesses.

IMARC’s information products include major market, scientific, economic and technological developments for business leaders in pharmaceutical, industrial, and high technology organizations. Market forecasts and industry analysis for biotechnology, advanced materials, pharmaceuticals, food and beverage, travel and tourism, nanotechnology and novel processing methods are at the top of the company’s expertise.

Our offerings include comprehensive market intelligence in the form of research reports, production cost reports, feasibility studies, and consulting services. Our team, which includes experienced researchers and analysts from various industries, is dedicated to providing high-quality data and insights to our clientele, ranging from small and medium businesses to Fortune 1000 corporations.

This release was published on openPR.

Posted on nosqlgooglealerts. Visit nosqlgooglealerts

Article originally posted on InfoQ. Visit InfoQ

Mistral AI recently released Mixtral 8x7B, a sparse mixture of experts (SMoE) large language model (LLM). The model contains 46.7B total parameters, but performs inference at the same speed and cost as models one-third that size. On several LLM benchmarks, it outperformed both Llama 2 70B and GPT-3.5, the model powering ChatGPT.

Mistral 8x7B has a context length of 32k tokens and can accept the Spanish, French, Italian, German, and English language. Besides the base Mixtral 8x7B model, Mistral AI also released a model called Mixtral 8x7B Instruct, which is fine-tuned for instruction-following using direct preference optimisation (DPO). Both models’ weights are released under the Apache 2.0 license. Mistral AI also added support for the model to the vLLM open-source project. According to Mistral AI:

Mistral AI continues its mission to deliver the best open models to the developer community. Moving forward in AI requires taking new technological turns beyond reusing well-known architectures and training paradigms. Most importantly, it requires making the community benefit from original models to foster new inventions and usages.

Mixture of Experts (MoE) models are often used in LLMs as a way to increase model size while keeping training and inference time low. The idea dates back to 1991, and Google applied it to Transformer-based LLMs in 2021. In 2022, InfoQ covered Google’s Image-Text MoE model LIMoE, which outperformed CLIP. Later that year, InfoQ also covered Meta’s NLB-200 MoE translation model, which can translate between any of over 200 languages.

The key idea of MoE models is to replace the feed-forward layers of the Transformer block with a combination of a router plus a set of expert layers. During inference, the router in a Transformer block selects a subset of the experts to activate. In the Mixtral model, the output for that block is computed by applying the softmax function to the top two experts.

The fine-tuned version of the model, Mistral 8x7B Instruct, was trained using DPO, instead of the RLHF technique used to train ChatGPT. This method was developed by researchers at Stanford University and “matches or improves response quality” compared to RLHF, while being much simpler to implement. DPO uses the same dataset as RLHF, a set of paired responses with one ranked higher than the other, but doesn’t require creating a separate reward function for RL.

Mistral AI evaluated their models on benchmarks for several tasks, including code generation, reading comprehension, mathematics, reasoning, and knowledge. Mistral 8x7B outperformed Llama 2 70B on nine of twelve benchmarks. It also outperformed GPT-3.5 on five benchmarks. According to Mistral AI, Mistral 8x7B Instruct’s score on the MT-Bench chatbot benchmark makes it “the best open-weights model as of December 2023.” The LMSYS leaderboard currently ranks the model 7th, above GPT-3.5, Claude 2.1, and Gemini Pro.

In a discussion on Hacker News, several users pointed out that while all of the model’s 46.7B parameters need to be loaded into RAM, inference speed would be comparable to a 13B parameter model. One user said:

This can fit into a Macbook Pro with integrated memory. With all the recent development in the world of local LLMs I regret I settled for only 24Gb RAM on my laptop – but the 13B models work great.

The Mixtral 8x7B and Mixtral 8x7B Instruct models are available on HuggingFace. Mistral AI also offers a hosted version of the model behind their mistral-small API endpoint.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Shapira: In my previous life, when I was still traveling, giving talks, I gave a talk in QCon, San Francisco in 2018. It was about the evolution of microservices. The last part was the future of microservices. I said that, serverless looks like an interesting step and an evolution. You have all those functions, which are very small serverless. It’s not clear how all those functions can interact with databases. Where do they store data? How do they set their state? Things were extremely unclear. When you looked around then like, which were serverless databases to match those serverless functions, it was like, we don’t really have many of them. There was Amazon DynamoDB. Snowflake was technically serverless in some respects back then, but nobody thought of it as serverless. Then there weren’t really a lot of other options. Fast forward to today, I only fit a partial list into this slide. Obviously, there is a lot of systems that say, we’re a serverless database. We were built for serverless workloads. We’re a database for the cloud. All those things are now all over the place. Obviously, in the last five years except other than the epidemic, other stuff has changed as well. Why is that? Why did we go from almost no serverless databases to now we have a lot of them? The cynical answer is to say it’s a buzzword, anyone who can put serverless in front of whatever they’re doing, goes and put serverless in front of whatever they’re doing. This is not incorrect but I think there is a lot more to it than that. This presentation will basically go through the reasons that serverless is happening right now.

Context

We’ll start with, one reason we have serverless right now is because we can. We are getting better at distributed systems. We have better guarantees, better algorithms, better foundations. We learned how to tame a lot of the issues that really made distributed databases a serious challenge, even just five years ago. We’re going to talk in detail about those different architectures that make serverless databases possible. The other side is because it’s worth it, because there is now a lot of workloads that actually benefit from running on a serverless database, as opposed to something a bit more traditional. I’m going to talk about in what cases is it worth it, and in what cases you should just stay exactly where you are, and nothing changed for you. The last point is because serverless in the form of Function as a Service is a big deal. Those are new workloads. They do have fundamentally different requirements. They do need data somewhere. We’ll talk about what the force that Function as a Service apply toward our data architectures. I’ll give some examples of data architectures that, I think, are particularly good for serverless functions.

I’m going to spend about half the talk talking about the internals of a bunch of serverless databases. Why am I going to tell you how to build a serverless database when clearly the vast majority of you are not going to go back and tell your boss, “I’m building a serverless database now.” I think you guys are in a position to choose technologies for yourself, for your teams, for your companies. This is what senior developers and architects do. Knowing and understanding the internals and the tradeoffs that were involved in creating those systems will allow you to make really good choices. This is the goal, to equip you in making good choices. If people here listening to my talk would say, “Until today, I thought that serverless is marketing BS. Now that I understand really what’s going on and the tradeoffs and the benefits, I think I may look a bit more into it.” If that’s what you say then, I’ve done my job.

Background

Until about a year and a half ago, I was leading cloud native Kafka for Confluent. I led this team of amazing engineers. Our goal was to build serverless Kafka experience for Confluent Cloud, when we said that we want serverless Kafka experience. Confluent marketing was very responsible, they never said serverless, we only said that internally. It was our vision, is that our users will only give us their workload, and the credit card, and that’s it. We will take care of everything else. You need more resources, you need something optimized, you need to move partition around, you need a different configuration, don’t worry about it, produce, consume, send us data, we will figure out the rest. When I say serverless, this is my mental model. As a vendor, it obviously meant that there was a lot on us. The usual, we have to be highly available, we had to never lose anyone’s data. Then we had to provide elasticity. Because they’re giving us a workload, we don’t know how much of it will be, and when it will show up. We need to be able to scale clusters up and down. It’s even more than just autoscale. Elasticity for me means being able to resolve hotspots, resolve noisy neighbors, really making sure that every part of the workload always has optimal performance at all times. It was a lot of smart people investing a lot in this. Fast forward a year and a half later, I’m building a new database with a much smaller team of amazing engineers. Because we’re building a new database, I get to rethink ideas about a lot of those architectures. This database is not quite ready yet. You cannot go to the website and start using it. It does mean that I’ve spent the last year and a half rethinking about how to build a modern database from first principles, looking at every bit of architecture, what works, what doesn’t, in what situation.

Architecture of Serverless DBs

Let’s talk about those architectures. As I mentioned before, the big problem that we’re trying to solve when we talk about serverless databases is elasticity. As the vendor, it behooves us to accept every bit of workload, and to make sure it works well. Otherwise, a workload that we have to reject is a workload we cannot charge someone for. It means that we need to take these systems and make them a lot more flexible than they were before. Typically, elasticity means that things have to autoscale. That’s interesting. From zero to basically whatever people usually measure, and so the cloud has no limits. It behooves you to have no limits. You want to do it in small increments, because people prefer to pay at small increments. I have one extra bite, now I have to buy this big extra machine that’s not exactly serverless. You want the resources you pay for to match what you’re actually doing. It has to be almost instantaneous. It used to be that scaling, I think, Aurora Serverless used to take 20 minutes until you get more resources. This thing is no longer acceptable. It has to be in response to load and utilization as opposed to someone clicking, I want more data button. In order to build all that, it’s a lot of difficult decisions and a lot of tradeoffs. Nobody does all those five elasticity requirements that I mentioned. We’re going to go over some of those decisions and really see how different decisions carry with them other different decisions. If you choose to have big multi-tenancy, there is a bunch of things you have to do. If you choose to have local storage, there’s a bunch of things you have to do. Those shape the systems that you’re looking at. If you’re looking at one type of database, you will see something very different because of the architecture. The thing that makes Amazon Aurora different from CockroachDB, different from DynamoDB, very different from Snowflake is, in many ways, those deep architectural decisions.

Shared-Nothing Architecture

Let’s start with one big architecture decision, the shared-nothing architecture. This should be at least slightly familiar, for the reasons that this is the old school architecture. Many people would say, this is not cloud native, or yes, some of the older cloud systems do it. It’s not really that. Systems that do it would be DynamoDB, Vitess, Yugabyte. Kafka and Confluent Cloud was one of those. There are successful systems built in this architecture, which is why I hate discounting it is not cloud native. DynamoDB did it, who knows if it’s not cloud native? The way the system is built is the essence you have data nodes. Data nodes own compute and local storage. This is obviously great if you believe that local storage is actually faster and more reliable than the storage clusters otherwise available. It’s obviously good as long as all the computation is local. There is a query router, usually routers whose job is to distribute the queries, and sometimes also consolidate the results. You try to minimize how much data is going in between the nodes, as much as possible. You try to keep every node independent. This also means making data modeling decisions. If you go and look at the Vitess documentation, they’ll have a big section on how to model data so it will work well in that model. Similarly, for DynamoDB and other systems.

You have this system, how do you scale it? That’s what a system means, first of all, you need to move things in and out. All the data in each of the data nodes is in the form of small partitions. You move them around, basically. You’re at the last node, you move partitions around, some of the partitions become highly loaded, you try to move them to a better place. The main solution is scale those data nodes out. Obviously, you can add query routers, you can add more metadata nodes. Transaction coordinator is the one that is actually much harder to scale out, in general. Usually, when those systems have scalability issues, it’s because you’re bottlenecking on transaction coordination in some way. Know that the key thing here, the ability to scale the whole thing is built on the fact that partitions are fairly small, and therefore you can move them around with fairly low latency, very little issues, even while the system can be quite loaded. This is how you resolve hotspots. In order to keep the partitions small enough, remember, people are reading and writing data all the time, how do you keep them small? Two main techniques. One of them is that you split them. Partition got above a certain size, it now becomes two partitions.

Again, very old technique. I don’t think I’m saying something new here, but still used in DynamoDB. It’s great if your partitioning scheme is hash partitioned or range partitions, these kinds of things work quite well. The other solution is what is also known as tiering, this is what Kafka did. The insight here is that you look at a partition and say, actually, only this small chunk at the top is valuable. Remember that Kafka is a log. Most of the reads and writes are on the top of the log. The top 10% get 90% of the load. This means that in order to keep it small, you can take the tail of the log and shove it into slower storage like S3. This keeps the main hot partition much smaller and allows you to move it around.

The other key part of the system is the rebalancing algorithms. The idea is that you have a lot of metrics about the load on the node level below the partition level. You have a process that continuously looks at all those metrics and says, this node is getting a bit loaded. It doesn’t have enough capacity. Let’s take some of the partitions and move them somewhere else where it makes sense. Or if there is no place where it makes sense and things are getting loaded, you need to actually add capacity. Those are really challenging. We had a lot of smart people spend a lot of time trying to get it right. Because we don’t want to move data too much, it takes resources, and those resources could be better used for something else. On the other hand, you do need sufficient spare capacity on every node to allow things to burst and to give you headroom to handle all kinds of situations. One of the things we learned is that you really want to aim at a lot of local decisions with some safeguards. You don’t want to come up with this amazing global plan for the entire cluster with the perfect placement for everything, because it takes a lot of time to compute this plan, in a large cluster it can be hours. As a result, by the time you finish computing and finish moving everything, the situation changed, cloud moves very fast, workloads change all the time. Don’t do that. Look for signal that things are getting highly loaded, like the 60-ish percent CPU, and start moving some things to a less loaded node, it will keep things, more or less, in balance over time. Obviously, if you find out that you move things between two nodes, or the same partition a lot, then you need to flag that something is off here, and maybe we’re doing useless work.

Compute-Storage Separation

The other big algorithm, compute-storage separation. This is the one that’s considered more cloud like. The Snowflake paper, I think, circa 2011, says, in the cloud, the architecture that takes the best advantage of the cloud system in order to provide elasticity and flexibility for the users is the compute-storage separation. Everyone looked and said, that looks like a good idea. A lot of those architectures showed up. The main idea is that you’re now running two clusters. You have a storage cluster, where the data is just, think about it as dumb blocks. S3 is a good example, or even EBS, you just have chunks of data stored in there. Any machine can reach out to anywhere in the storage cluster to grab any set of blocks. The responsibility of the storage cluster is basically, don’t lose blocks, and be available. That’s the main thing. Also, you can push more down into it and ask it to do a bit more. Compute nodes are the ones that do the majority of whatever you need your system to be: filters, joins, aggregates, whatever you need from your compute layer, this is where it’s happening. The key to this system’s performance is that you want things in the compute node to be logically cohesive so you can take good advantage of caching, because remember the storage node, you have to reach out to another cluster. Then joins require obviously a lot of data locality. You are looking for ways to get everything you need for specific workload on one compute node. If you go to Snowflake, they will ask you to define multiple data warehouses. Those data warehouses are essentially compute nodes. If you need more compute, you will buy additional data warehouses.

Aurora/Snowflake Scaling

How do you scale those? There is basically two methods of scaling them. We’ll start with the Aurora/Snowflake type of scaling. Storage cluster is easy. It’s, again, a cluster of bytes of data. You add additional nodes, they will replicate things over, stuff will move over. In many ways, the storage cluster still acts like shared-nothing cluster, except it’s a storage cluster. The compute nodes on the other hand, in the Aurora model, they don’t scale out, they scale up, meaning that every compute node is essentially a database. This has amazing advantages because it means that you can look at it like it’s a normal database. You don’t have to think hard about how do I partition data correctly. You don’t have to think about, some of my data is not local, and if I have transactions, I have to do some logs and they take extra time. You basically use it normally. If and when things get loaded, they have nice ways to take the container with the database, with its entire state, with all the connections, with all of everything, and either give it more space on the spot, which is I think fairly easy with modern containers. Or if the entire physical node is busy, they can move it. It should be transparent. In reality, you will see a blip in your latency graph when this happens. It’s not as transparent as many want it to be.

With this model, it has two interesting benefits on what you get from it. One of them is that the compute-storage separation means that you can do nice things like spin up another compute node, and point it at the same storage and set up Copy-on-Write. This essentially just created a branch of your database. Delphix did it ages ago. This is obviously much easier because you just do a click. You don’t have to actually run the whole thing. It’s Aurora, it runs in the cloud. This situation is nice. Obviously, it has limits on how much it can scale up that are a bit harder to solve. Back in the day when we were all in data centers, there was this thing where everyone used those big storage clusters, like EMC and stuff. Then there was always this big Oracle database that whenever it took its weekly full backup, usually on Friday at 3 a.m., everything else would grind to a halt. It doesn’t happen quite that badly on Aurora, but you definitely sometimes notice that the storage cluster that you’re on is a bit busier than normal. You see some noise from that as well.

Spanner/CockroachDB

The other approach to compute-storage separation is the one that was started with the Spanner paper, and CockroachDB has this system. Which is that you separate compute and storage, but you also scale out the compute nodes. How do you maintain things like transactional integrity when you have compute nodes, every one of them handling their own workloads and their own transactions? This is where things get pretty complex. They use things like Raft and Paxos to maintain transaction logs. You have to get consensus on transactions, so all the compute nodes, basically. The storage cluster is not just write data, it is, maintain transaction guarantees. It has to log all the transaction guarantees. Both Spanner and Cockroach, they’re at global scale. Things like Raft and Paxos are extremely efficient in a data center. The moment you start trying to make them global, they actually lose a lot of their efficiencies. They’re a bit too chatty for a lot of back and forth. In those cases, it’s common to have two-phase commit to the other side of the globe. You need to be aware that you cannot really stop doing transactions. If you’re on Spanner or Cockroach, you’re there because you want transaction guarantees, like most normal engineers who discover that they actually want to know what the data is at the end of the day. You have to remember that, in this scenario, you can scale out impressively. There will be slowdowns related to transaction if they cross the globe.

Key Lessons

The big lesson is that there is no free lunch. You have to understand the tradeoffs. If I go with Aurora, I have to not think about some things, I have to think about other things. Transactions are not an issue. Cold start is an issue, minimum payment may be an issue. If I go with something like DynamoDB, then things are perfect, but I have a key-value store. There’s all kinds of things to take into consideration and make sure that you understand what each system is actually capable of delivering. The one thing to note is that while you will have to make tradeoffs, if you decide you want a very elastic system, look at the situation. It does not require changing the whole way you ever use the database. Meaning if you like key-value stores, there will be several for you to choose from. If you like relational, there will be a bunch. If you like specific type of relational, and MySQL fans will be. If you like Postgres, there are going to be. You don’t have to change a lot about your worldview. This is not the same case if you try serverless functions, which is, learn a whole new way to write code and manage code and so on, because I’m still trying to wrap my head around how to build functionality from a lot of small independent functions. The other thing is that every rubric has different latency tradeoffs. Aurora would have the spikes and a bit of noise. If you have the systems that move stuff around, you might notice the changes in performance as stuff moves around. The vendor may do maintenance at times. This will have an impact that you may notice in the graph. You need to understand what you’re getting. You need to also understand your alternatives. This is the important thing. I’ve seen a lot of cases where people are looking and saying, “I can’t use it, because I cannot afford any performance spikes.” Those performance spikes happen when we scale up, which means that the machine that you already have is not big enough. What happens to you today when the machine you have is not big enough? You have bad performance anyway, except this one goes away after a few seconds, and the other one actually gets worse and stuff queue up. I’ve seen situations where performance requirements were unrealistic, even for a provisioned system with the best engineers in the world trying to make it work, or was extremely cost prohibitive, and the customer was very clear that the cost is not going to work for them.

At the end of the day, the cloud is just someone else’s computer. A lot of people imagine that problems will be magically solved if we move workloads to the cloud. I think a lot of cloud vendors encourage the magical thinking around it. At the end of the day, it is computers and databases run by the best experts in the world with a lot of time and money to make it happen. There are some requirements that even the best in the world cannot really do. Think long and hard about, if I’m not using this, what will be the alternative. Will I actually get what I need in other situations? The other thing about low latency in general, testing and more testing. These things are dependent on the cloud vendor and the region that you’re in. If you’re on U.S.-East-1, the chances of noise are a lot higher than if you are in a small cluster in the South East Pacific. It obviously depends on your workload. If you’re connection heavy, it will be very different than if you are doing huge computations than if you’re reading massive amounts of data, throughput, IOPS, all those things, test and test. You don’t even know what is the low latency and how inconsistent things are, until you try them out.

When Do You Need Serverless DBs?

With that in mind, all these does not matter if you don’t actually need a serverless database. Let’s talk about this. I’m going to talk about a bunch of scenarios. Let’s start with the easy one. You’re a small company. You have one workload, and it’s pretty stable. You’re still not growing that much or that fast, or maybe you’re growing pretty fast, but because it’s one workload, you can plan a trajectory ahead. This is great. Life is good. Just figure out how much space you need for a one server workload and move on with your life. Maybe putting something in your calendar once every three months to take a look to check if it’s ok again. Some things are not broken, enjoy them. Now, as stuff get bigger, usually you start having multiple workloads, but sometimes all of them are fine. This is harder. You still have to understand how they interact with each other. You still have to worry about having enough space for this one crazy guy who may do something. Planning capacity is harder. Tuning can be a lot harder because those workloads may actually conflict and require different things. Because they’re fairly stable, it’s almost a one-time investment. You do it for every one of your workloads, and they don’t change much, and you can move on with your life. This is still ok. If you have enough people to do it, your life is still fine.

Where things get hairy, when you have a lot of variability. Variability can be in a day, it can be in a month, it can be this time of year when stuff start jumping. All of those can be variability. It can be more predictable variability. It can also be very unpredictable variability. The fact is that if your workload is very variable, you need a lot of spare capacity. Otherwise, when you hit the peak, it will not work, flat and simple. The problem with having a lot of spare capacity, is that if you look at how much your company’s customers pay, how much value your company derives from the database, it’s actually along the lines of the average. Your customers don’t get value when there is no workload, essentially. There is a big gap, especially this day and age. I’ve been through the 2000 recession. I’ve been through the 2008 recession. Here we are today, executives ask a lot of questions. Why do we need all those databases that are only at 20% capacity? Why can’t we put them all together and have something at 80% capacity? We all know the answer. It’s, in general, a lot of conversations that is amazingly pleasant to have. Even more along, if it’s a relatively small system, 70% spare capacity sounds like a lot, but it actually may not be that much in actual workload. It may be just a few extra megabytes. In this situation, that’s where actually moving to serverless cluster, from a cloud vendor, is very reasonable. Why? Because that’s the whole point of the serverless cost model is that you’re paying for what you use. The executives will be happy because they are finally paying for the value delivered. You will not have to think about how to capacity plan for the peak of demand, that who knows how high it will be and then get paged when you didn’t plan enough. You will not have to sit through meetings of, am I provisioning too much or too little? Because, who knows? How do you even know? This is exactly when it makes a lot of sense to push the problem to someone else.

There is an even more fun situation. If you work for a place that is especially crazy, you may have a lot of workloads that are highly variable. This is true, especially if you’re working for a larger company, especially one that does good business across the globe. Then, you have the peaks for the IPL in India versus Thanksgiving in the U.S., and all those things have to come together. This is a nightmare if you’re trying to manage it. I’ve been there a few times, it was always a gigantic headache. If you set up a serverless system yourself, it puts you in a position where you can be your own cloud provider in a way. If instead of giving every workload its own machine, you can actually create large clusters that those workloads can be elastic inside. It means that you can have a lot lower spare capacity, but because it’s spread out across many machines, it’s actually a lot more capacity in practice. Twenty percent spare capacity on a very large cluster can be 10 and more times bigger than 70% spare capacity on a small cluster. Mathematics. It does mean that you need one of those solutions, moving stuff around, or offloading things to S3, or all of the above. It really means that you can get the benefits of this elasticity in your data center, which is extremely cool. To summarize, basically, the more tenants you have, and the more variability you have in your workloads, the more serverless would make sense for you, from both economic perspective and from lack of headache perspective. You don’t have to capacity plan for the unplannable, is the main point here. I know that many times people think that serverless DBs may be like, yes, maybe in some situations. I think it may make more sense than you believe, and worthwhile checking if you could benefit from cost savings and less time spent trying to predict the future.

Function as a Service (FaaS)

The last point is, how does Function as a Service fit in, and the force that it applies on a database? Serverless databases are useful, even if you don’t use Function as a Service. If you do use Function as a Service, you absolutely need a serverless database. How many of you use Function as a Service? The main point is that the more your workload is variable, the more risk it poses to your database. Function as a Service, by definition, is the most variable workload possible. It can burst from zero to hundreds and thousands of connections and requests per second in an eyeblink. It can and has killed very large clusters, because it’s essentially a tool for self DDoS. It’s impossible to capacity plan for something that can scale from zero to thousands without blinking. This is obviously a big concern. There are other concerns. There is no local state, it means that there is no connection pooling. We will have to start connections. It will mean that it will have to read all the data it needs from the database as fast as possible when it starts. Obviously, people who are running it are paying for execution time, so they will get extremely upset when it takes a long time to gather data from database to do a thing.

Two common architectures for this situation, the simple one and then the one that actually works. The simple one is basically, have all the functions connect directly to the database. It works. It works in some situations. The database, first of all, has to make it extremely cheap to start new connections. This is true for every serverless database out there, they add a proxy, or they make modifications to the protocol, they make modifications to the database itself. They have to make it cheap. This is important. Not true for every database that was not built to be serverless, especially if you have MySQL, Postgres, you may know, every connection is an entire process. You have to be very careful about things that show up, start the connection, run a single query, and disappear. The other situation where it makes sense, obviously, is databases have to be extremely elastic, because you don’t know if it will be one function right now, and in two seconds, it will be a thousand of them. You want it to be very close geographically to the functions. Again, not bad in the cloud, if you have databases in a lot of places. It’s important, because, again, time is money in serverless world, and getting data over larger distances take longer than getting data over shorter distances. Remember that they have no state, they’re never going to cache anything. Forget about, the application will cache stuff, which we’ve all gotten used to over the last 30 years of doing databases and backends.

The ones that I think works in most situations, even though it’s a bit more effort, is to have something between those functions in the database. This something can be a lot of things. It can be a backend, because as much as I love Function as a Service, I still don’t believe that our entire business logic will ever be managed in tiny independent functions out there in the cloud. I think we will always do some stuff maybe in those functions, but most of the core business logic will be in an actual backend with actual services. Functions will connect to the backend, the backend can have stable database connections that will bring some stability to the thing. The other option is to have a proxy, which will make connections. Again, it will provide a stable connection pool. If you can throw in a cache, so much better, because it means that functions don’t have to wait for the database, essentially. I’m putting it like as a three-tier architecture here, partially for space and familiarity, but know that you can have as many layers of this as you want and need. Think about it like a CPU, L1 cache, L2 cache, L3 cache, all those things. Have one cache very close to the database, have one very close to the functions. Have some logic in between. It’s actually not trivial to manage. Again, at the very least, having one layer that is backend business logic, and caching, and provides this permanent connection pool, I think makes a lot of sense in almost every situation.

Summary

If you’re going to use serverless, dig very deeply into the architecture and the tradeoffs, because not all serverless are made the same. There is higher likelihood than you think that you are going to benefit from a serverless database, because they take off a lot of the capacity planning, picking a machine, tuning things, and then scale-in, scale-out as needed, and they can save you some money. If you use Function as a Service, you need a serverless database, and you probably need a bunch of layers in between as well.

Questions and Answers

I think there’s a lot of challenges in sharding your database, East Coast, West Coast, in general. This one is actually fairly reasonable. DNS does allow you to have locality, and AWS does have services that tell you, route connections to the lower latency location.

Participant 1: Does that mean that when I do sharding I’m required to keep the code on both data.

Shapira: Is that the expensive option? Usually, you say, we have some customers in the East Coast and their data is in the East Coast. Especially important, if you have customers in Europe, it’s really important for them that their data will be only in Europe. Nothing that I said solves data locality for you, which is a lot more complex than just performance. Because you have regulations, where is data allowed to live? How long can you keep it in each location, and so on?

Participant 2: You mentioned the two types of architectures, mainly two types. One is storage-compute separation, and the other is shared-nothing. I feel that even both of these have some kind of storage, though. Even in the shared-nothing architecture, your computing is still as far as you know it. I think there’s still some similarities in scaling like the storage unit of the two types of architectures. Is that correct?

Shapira: It’s absolutely correct. I think it depends, like there’s always a lot of [inaudible 00:41:40]. Because for example, if you take your compute nodes, and the storage is actually EBS, you already have a storage cluster. It’s a bit too limited. It doesn’t let you share it, essentially, so you can’t use it as shared storage for the entire cluster, for the data cluster, but it is a cluster. This was very true up to maybe a year or two ago. Even the highest tier EBS is not the same performance as you get from local SSDs with some NVMe running, and all that. In some cases, when we talk about keeping compute and storage together, I’m mostly talking about places where you really keep them physically together on the same box, like the way we used to sell Hadoop, back in the day, essentially. There’s a lot of benefits for bringing compute and storage together. Reading from storage, for example, is way faster, higher bandwidth, and so on. You have less bottlenecks in between, which are a lot of times a problem if you have the separation. If you are going to put compute resources together, put them really together, otherwise, you definitely don’t get the full benefits of putting them together. If you separate them out, then you need to separate them out to storage that actually gives you the capabilities that you need. There’s a lot of in-betweens. If that was Snowflake, they use S3 as their offline storage that can be shared. The data nodes because they are long lasting, and they don’t scale out and so on, they actually store a lot of data locally. It’s just that the local data they call it cache. It’s cache sitting right there on SSDs, and has more space. They call it cache because if you lose the entire machine, they can rehydrate. I showed it as like either this or that, but there’s actually a lot of variations in between.

Participant 2: Actually, there’s maybe a hybrid model of shared-nothing, and the storage and compute separate model. Some of the analytical databases normally complain that they don’t work with both models. I think maybe StarRocks is one of those. They claim that if you want high performance, you need to import the data from cloud storage to their own storage. I think probably at that time, they may do some compute and storage bundled together. You can also just read data remotely from cloud storage. What do you think about this model?

Shapira: I would go as far as I say that everything there is a continuum. I think there’s very little in the pure coupled compute and storage and there’s very little in the fully decoupled, and having more models that allow you to place yourself in this continuum. Because the whole goal is to optimize performance in certain situations, and to allow for scale-out in other situations. The hybrid model, which is, say, you have virtually unlimited storage, because it’s all on a big storage cluster, but you also get the high performance because you’re loading things into a local machine. I think this is what almost everyone is doing behind the scenes. For me, it’s more, do you want to have this control over what you’re building in, or do you prefer your vendor to more automatically do it based on what they think they’ll control, and they’ll have their own cache policies. It sounds like it’s maybe more about control and maybe this model gives you amazing performance for your situation. Then some people would prefer slightly less control and it may work for them.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

The recent report from Rising Stars highlights the trends in the JavaScript ecosystem and showcases standout projects based on GitHub Stars in 2023. Overall, the most popular project was shadcn/ui, a collection of UI components that can be used to create custom components. The JavaScript runtime Bun continued its momentum, making it the second most popular project. Excalidraw, an open-source virtual hand-drawn style whiteboard, gained popularity.

Shadcn/ui, now a year old since its first commit on GitHub, is a collection of reusable components that can be copied and pasted into apps to build components. This eliminates the need to install the library. According to shadcn/ui FAQ page, the idea is to

… give you ownership and control over the code, allowing you to decide how the components are built and styled.

Shadcn/ui can be used with frameworks that support React such as Next js, Astro, Remix and Gatsby.

Bun, which claimed second in the overall most popular project, is a JavaScript runtime, package manager, test runner, and bundler that gained attention for its speed, efficiency, and comprehensive toolkit. Developed in the Zig programming language, Bun aims to be a replacement for Node.js.

In the frontend framework list, React continued to hold its ground as a frontrunner in the JavaScript ecosystem. Secondly, Htmx took the lead as a JavaScript library enabling developers to create interactive web applications using HTML alone. This is achieved by extending HTML with new attributes that trigger HTTP requests and handle response data, allowing the development of modern web applications without extensive JavaScript code.

Securing the third spot in front-end frameworks was Svelte. Svelte is a compiler-based frontend framework that uses declarative syntax and reactivity to build performant and maintainable web applications. The anticipated major release, Svelte 5 is expected to introduce significant improvements and new features to further enhance the development experience and application performance.

In the Vue ecosystem, the community navigated the sunset of Vue 2, with efforts to upgrade to version 3 supported by frameworks like Nuxt, Vuetify, and PrimeVue. Nuxt was ranked as the most popular Vue framework.

Next.js maintained its dominance in the back-end/full-stack category. Next.js 14 was released in 2023 and the most notable changes are Turbopack Optimizations for faster initial page load times, improved performance, and reduced code size. Server Actions Stability is now stable and Partial Prerendering(preview), a technique that pre-renders only parts of an application, is introduced as a preview feature. Astro climbed the rankings with its innovative static site generation and dynamic page generation capabilities.

In the mobile space, Expo, Tamagui, and Nativewind led efforts to unify web and native development experiences, maximizing code reuse and increasing accessibility for web developers. React Native maintained its dominance, but a shift toward more opinionated solutions indicated evolving paradigms in mobile development.

Posted on mongodb google news. Visit mongodb google news

Notice: Information contained herein is not and should not be construed as an offer, solicitation, or recommendation to buy or sell securities. The information has been obtained from sources we believe to be reliable; however no guarantee is made or implied with respect to its accuracy, timeliness, or completeness. Authors may own the stocks they discuss. The information and content are subject to change without notice. *Real-time prices by Nasdaq Last Sale. Realtime quote and/or trade prices are not sourced from all markets.

© 2000-2024 Investor’s Business Daily, LLC All rights reserved

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

Posted on mongodb google news. Visit mongodb google news

JMP Securities reaffirmed their market outperform rating on shares of MongoDB (NASDAQ:MDB – Free Report) in a research note issued to investors on Monday morning, Benzinga reports. They currently have a $440.00 target price on the stock.

A number of other analysts also recently weighed in on the company. Capital One Financial upgraded MongoDB from an equal weight rating to an overweight rating and set a $427.00 price target for the company in a report on Wednesday, November 8th. Barclays boosted their price target on MongoDB from $470.00 to $478.00 and gave the company an overweight rating in a research note on Wednesday, December 6th. Needham & Company LLC reaffirmed a buy rating and set a $495.00 price objective on shares of MongoDB in a research report on Wednesday, January 17th. Scotiabank assumed coverage on shares of MongoDB in a research report on Tuesday, October 10th. They set a sector perform rating and a $335.00 target price on the stock. Finally, UBS Group reissued a neutral rating and set a $410.00 target price (down from $475.00) on shares of MongoDB in a research note on Thursday, January 4th. One equities research analyst has rated the stock with a sell rating, three have given a hold rating and twenty-one have given a buy rating to the stock. Based on data from MarketBeat.com, MongoDB currently has a consensus rating of Moderate Buy and an average price target of $430.41.

Read Our Latest Report on MDB

MongoDB Price Performance

Shares of MDB opened at $413.42 on Monday. The business has a 50-day moving average of $401.48 and a 200-day moving average of $380.52. The company has a debt-to-equity ratio of 1.18, a current ratio of 4.74 and a quick ratio of 4.74. The company has a market capitalization of $29.84 billion, a price-to-earnings ratio of -156.60 and a beta of 1.23. MongoDB has a 1 year low of $179.52 and a 1 year high of $442.84.

MongoDB (NASDAQ:MDB – Get Free Report) last released its quarterly earnings results on Tuesday, December 5th. The company reported $0.96 earnings per share (EPS) for the quarter, topping the consensus estimate of $0.51 by $0.45. MongoDB had a negative net margin of 11.70% and a negative return on equity of 20.64%. The firm had revenue of $432.94 million during the quarter, compared to analyst estimates of $406.33 million. During the same quarter last year, the business earned ($1.23) EPS. The company’s revenue was up 29.8% compared to the same quarter last year. As a group, equities research analysts anticipate that MongoDB will post -1.64 earnings per share for the current year.

Insider Buying and Selling

In related news, CRO Cedric Pech sold 1,248 shares of the business’s stock in a transaction dated Tuesday, January 16th. The shares were sold at an average price of $400.00, for a total value of $499,200.00. Following the transaction, the executive now directly owns 25,425 shares of the company’s stock, valued at approximately $10,170,000. The sale was disclosed in a legal filing with the Securities & Exchange Commission, which is available through this link. In other MongoDB news, CFO Michael Lawrence Gordon sold 21,496 shares of the firm’s stock in a transaction on Monday, November 20th. The stock was sold at an average price of $410.32, for a total value of $8,820,238.72. Following the completion of the sale, the chief financial officer now directly owns 89,027 shares of the company’s stock, valued at $36,529,558.64. The transaction was disclosed in a document filed with the Securities & Exchange Commission, which is accessible through this link. Also, CRO Cedric Pech sold 1,248 shares of the business’s stock in a transaction on Tuesday, January 16th. The shares were sold at an average price of $400.00, for a total value of $499,200.00. Following the completion of the sale, the executive now owns 25,425 shares in the company, valued at $10,170,000. The disclosure for this sale can be found here. Over the last three months, insiders have sold 148,277 shares of company stock worth $56,803,711. 4.80% of the stock is owned by company insiders.

Institutional Investors Weigh In On MongoDB

Large investors have recently added to or reduced their stakes in the company. Hutchens & Kramer Investment Management Group LLC bought a new stake in MongoDB during the 4th quarter valued at $202,000. Chicago Capital LLC bought a new stake in shares of MongoDB during the 4th quarter valued at $538,000. Mayflower Financial Advisors LLC raised its stake in shares of MongoDB by 7.5% during the 4th quarter. Mayflower Financial Advisors LLC now owns 716 shares of the company’s stock valued at $293,000 after purchasing an additional 50 shares during the period. ICICI Prudential Asset Management Co Ltd purchased a new stake in MongoDB during the 4th quarter worth about $283,000. Finally, Realta Investment Advisors bought a new position in MongoDB in the 4th quarter worth about $212,000. Hedge funds and other institutional investors own 88.89% of the company’s stock.

About MongoDB

(Get Free Report)

MongoDB, Inc provides general purpose database platform worldwide. The company offers 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-premise, 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

Posted on nosqlgooglealerts. Visit nosqlgooglealerts

Ratings for MongoDB MDB were provided by 12 analysts in the past three months, showcasing a mix of bullish and bearish perspectives.

The table below provides a snapshot of their recent ratings, showcasing how sentiments have evolved over the past 30 days and comparing them to the preceding months.

The 12-month price targets assessed by analysts reveal further insights, featuring an average target of $460.0, a high estimate of $500.00, and a low estimate of $410.00. This current average reflects an increase of 6.56% from the previous average price target of $431.67.

Diving into Analyst Ratings: An In-Depth Exploration

The perception of MongoDB by financial experts is analyzed through recent analyst actions. The following summary presents key analysts, their recent evaluations, and adjustments to ratings and price targets.

Key Insights:

• Action Taken: Analysts respond to changes in market conditions and company performance, frequently updating their recommendations. Whether they ‘Maintain’, ‘Raise’ or ‘Lower’ their stance, it reflects their reaction to recent developments related to MongoDB. This information offers a snapshot of how analysts perceive the current state of the company.
• Rating: Gaining insights, analysts provide qualitative assessments, ranging from ‘Outperform’ to ‘Underperform’. These ratings reflect expectations for the relative performance of MongoDB compared to the broader market.
• Price Targets: Analysts predict movements in price targets, offering estimates for MongoDB’s future value. Examining the current and prior targets offers insights into analysts’ evolving expectations.

Navigating through these analyst evaluations alongside other financial indicators can contribute to a holistic understanding of MongoDB’s market standing. Stay informed and make data-driven decisions with our Ratings Table.

Stay up to date on MongoDB analyst ratings.

About MongoDB

Founded in 2007, MongoDB is a document-oriented database with nearly 33,000 paying customers and well past 1.5 million free users. MongoDB provides both licenses as well as subscriptions as a service for its NoSQL database. MongoDB’s database is compatible with all major programming languages and is capable of being deployed for a variety of use cases.

Understanding the Numbers: MongoDB’s Finances

Market Capitalization: Surpassing industry standards, the company’s market capitalization asserts its dominance in terms of size, suggesting a robust market position.

Revenue Growth: MongoDB displayed positive results in 3 months. As of 31 October, 2023, the company achieved a solid revenue growth rate of approximately 29.77%. This indicates a notable increase in the company’s top-line earnings. As compared to its peers, the company achieved a growth rate higher than the average among peers in Information Technology sector.

Net Margin: The company’s net margin is a standout performer, exceeding industry averages. With an impressive net margin of -6.77%, the company showcases strong profitability and effective cost control.

Return on Equity (ROE): MongoDB’s ROE surpasses industry standards, highlighting the company’s exceptional financial performance. With an impressive -3.16% ROE, the company effectively utilizes shareholder equity capital.

Return on Assets (ROA): MongoDB’s ROA stands out, surpassing industry averages. With an impressive ROA of -1.1%, the company demonstrates effective utilization of assets and strong financial performance.

Debt Management: MongoDB’s debt-to-equity ratio is below the industry average at 1.22, reflecting a lower dependency on debt financing and a more conservative financial approach.

Understanding the Relevance of Analyst Ratings

Analysts are specialists within banking and financial systems that typically report for specific stocks or within defined sectors. These people research company financial statements, sit in conference calls and meetings, and speak with relevant insiders to determine what are known as analyst ratings for stocks. Typically, analysts will rate each stock once a quarter.

Some analysts publish their predictions for metrics such as growth estimates, earnings, and revenue to provide additional guidance with their ratings. When using analyst ratings, it is important to keep in mind that stock and sector analysts are also human and are only offering their opinions to investors.

This article was generated by Benzinga’s automated content engine and reviewed by an editor.

Posted on mongodb google news. Visit mongodb google news

MongoDB (NASDAQ:MDB – Get Free Report)‘s stock had its “market outperform” rating reaffirmed by analysts at JMP Securities in a note issued to investors on Monday, Benzinga reports. They currently have a $440.00 price target on the stock. JMP Securities’ price target would indicate a potential upside of 5.80% from the stock’s previous close.

A number of other brokerages also recently issued reports on MDB. Piper Sandler lifted their price target on MongoDB from $425.00 to $500.00 and gave the company an “overweight” rating in a research report on Wednesday, December 6th. UBS Group restated a “neutral” rating and issued a $410.00 target price (down previously from $475.00) on shares of MongoDB in a research report on Thursday, January 4th. Wells Fargo & Company began coverage on MongoDB in a research report on Thursday, November 16th. They issued an “overweight” rating and a $500.00 target price for the company. Tigress Financial raised their target price on shares of MongoDB from $490.00 to $495.00 and gave the stock a “buy” rating in a report on Friday, October 6th. Finally, Needham & Company LLC restated a “buy” rating and issued a $495.00 target price on shares of MongoDB in a report on Wednesday, January 17th. One equities research analyst has rated the stock with a sell rating, three have assigned a hold rating and twenty-one have issued a buy rating to the company. Based on data from MarketBeat.com, the company presently has a consensus rating of “Moderate Buy” and an average target price of $430.41.

View Our Latest Analysis on MongoDB

MongoDB Stock Performance

MDB traded up $14.82 during trading hours on Monday, hitting $415.87. The stock had a trading volume of 1,492,388 shares, compared to its average volume of 1,379,851. The company’s fifty day simple moving average is $400.77 and its 200 day simple moving average is $380.41. MongoDB has a 1 year low of $179.52 and a 1 year high of $442.84. The stock has a market cap of $30.02 billion, a PE ratio of -157.06 and a beta of 1.23. The company has a quick ratio of 4.74, a current ratio of 4.74 and a debt-to-equity ratio of 1.18.

MongoDB (NASDAQ:MDB – Get Free Report) last posted its earnings results on Tuesday, December 5th. The company reported $0.96 earnings per share for the quarter, beating analysts’ consensus estimates of $0.51 by $0.45. The business had revenue of $432.94 million during the quarter, compared to analyst estimates of $406.33 million. MongoDB had a negative return on equity of 20.64% and a negative net margin of 11.70%. The company’s quarterly revenue was up 29.8% compared to the same quarter last year. During the same quarter in the previous year, the firm earned ($1.23) EPS. Equities analysts anticipate that MongoDB will post -1.64 earnings per share for the current year.

Insider Buying and Selling

In related news, CEO Dev Ittycheria sold 100,500 shares of MongoDB stock in a transaction dated Tuesday, November 7th. The stock was sold at an average price of $375.00, for a total value of $37,687,500.00. Following the completion of the sale, the chief executive officer now directly owns 214,177 shares in the company, valued at approximately $80,316,375. The transaction was disclosed in a filing with the Securities & Exchange Commission, which is available through this link. In other MongoDB news, Director Dwight A. Merriman sold 4,000 shares of the business’s stock in a transaction dated Friday, November 3rd. The stock was sold at an average price of $332.23, for a total transaction of $1,328,920.00. Following the completion of the sale, the director now directly owns 1,191,159 shares in the company, valued at approximately $395,738,754.57. The transaction was disclosed in a filing with the SEC, which is available at the SEC website. Also, CEO Dev Ittycheria sold 100,500 shares of the business’s stock in a transaction that occurred on Tuesday, November 7th. The shares were sold at an average price of $375.00, for a total value of $37,687,500.00. Following the transaction, the chief executive officer now owns 214,177 shares of the company’s stock, valued at $80,316,375. The disclosure for this sale can be found here. In the last ninety days, insiders sold 148,277 shares of company stock worth $56,803,711. 4.80% of the stock is owned by corporate insiders.

Institutional Inflows and Outflows

A number of hedge funds have recently made changes to their positions in MDB. GPS Wealth Strategies Group LLC purchased a new position in MongoDB in the 2nd quarter worth approximately $26,000. KB Financial Partners LLC purchased a new position in MongoDB in the 2nd quarter worth approximately $27,000. Capital Advisors Ltd. LLC lifted its holdings in MongoDB by 131.0% in the 2nd quarter. Capital Advisors Ltd. LLC now owns 67 shares of the company’s stock worth $28,000 after purchasing an additional 38 shares in the last quarter. Bessemer Group Inc. purchased a new position in MongoDB in the 4th quarter worth approximately $29,000. Finally, BluePath Capital Management LLC purchased a new stake in shares of MongoDB during the 3rd quarter worth approximately $30,000. 88.89% of the stock is currently owned by institutional investors.

MongoDB Company Profile

(Get Free Report)

MongoDB, Inc provides general purpose database platform worldwide. The company offers 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-premise, 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

Click the link below and we’ll send you MarketBeat’s list of seven best retirement stocks and why they should be in your portfolio.

Get This Free Report

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

Posted on mongodb google news. Visit mongodb google news

Wealthfront Advisers LLC boosted its holdings in MongoDB, Inc. (NASDAQ:MDB – Free Report) by 13.4% during the 3rd quarter, according to its most recent disclosure with the Securities & Exchange Commission. The institutional investor owned 4,004 shares of the company’s stock after buying an additional 472 shares during the quarter. Wealthfront Advisers LLC’s holdings in MongoDB were worth $1,385,000 at the end of the most recent reporting period.

Several other large investors have also bought and sold shares of MDB. Simplicity Solutions LLC boosted its stake in shares of MongoDB by 2.2% during the second quarter. Simplicity Solutions LLC now owns 1,169 shares of the company’s stock valued at $480,000 after purchasing an additional 25 shares in the last quarter. AJ Wealth Strategies LLC boosted its stake in shares of MongoDB by 1.2% during the second quarter. AJ Wealth Strategies LLC now owns 2,390 shares of the company’s stock valued at $982,000 after purchasing an additional 28 shares in the last quarter. Assenagon Asset Management S.A. lifted its stake in shares of MongoDB by 1.4% in the second quarter. Assenagon Asset Management S.A. now owns 2,239 shares of the company’s stock worth $920,000 after acquiring an additional 32 shares during the period. Veritable L.P. lifted its stake in shares of MongoDB by 1.4% in the second quarter. Veritable L.P. now owns 2,321 shares of the company’s stock worth $954,000 after acquiring an additional 33 shares during the period. Finally, Choreo LLC lifted its stake in shares of MongoDB by 3.5% in the second quarter. Choreo LLC now owns 1,040 shares of the company’s stock worth $427,000 after acquiring an additional 35 shares during the period. 88.89% of the stock is owned by institutional investors and hedge funds.

MongoDB Trading Up 2.3 %

MDB stock opened at $401.05 on Monday. The stock’s fifty day simple moving average is $400.77 and its two-hundred day simple moving average is $380.41. The company has a debt-to-equity ratio of 1.18, a current ratio of 4.74 and a quick ratio of 4.74. MongoDB, Inc. has a 1-year low of $179.52 and a 1-year high of $442.84.

MongoDB (NASDAQ:MDB – Get Free Report) last posted its quarterly earnings data on Tuesday, December 5th. The company reported $0.96 earnings per share for the quarter, topping the consensus estimate of $0.51 by $0.45. MongoDB had a negative return on equity of 20.64% and a negative net margin of 11.70%. The business had revenue of $432.94 million for the quarter, compared to analysts’ expectations of $406.33 million. During the same quarter in the previous year, the firm earned ($1.23) earnings per share. The business’s revenue was up 29.8% on a year-over-year basis. On average, equities analysts expect that MongoDB, Inc. will post -1.64 EPS for the current year.

Insiders Place Their Bets

In other MongoDB news, Director Dwight A. Merriman sold 4,000 shares of the business’s stock in a transaction on Friday, November 3rd. The stock was sold at an average price of $332.23, for a total value of $1,328,920.00. Following the transaction, the director now owns 1,191,159 shares of the company’s stock, valued at $395,738,754.57. The transaction was disclosed in a legal filing with the SEC, which can be accessed through the SEC website. In other news, Director Dwight A. Merriman sold 4,000 shares of the company’s stock in a transaction on Friday, November 3rd. The stock was sold at an average price of $332.23, for a total transaction of $1,328,920.00. Following the transaction, the director now owns 1,191,159 shares of the company’s stock, valued at approximately $395,738,754.57. The sale was disclosed in a legal filing with the Securities & Exchange Commission, which can be accessed through this link. Also, CAO Thomas Bull sold 359 shares of the company’s stock in a transaction on Tuesday, January 2nd. The shares were sold at an average price of $404.38, for a total value of $145,172.42. Following the transaction, the chief accounting officer now directly owns 16,313 shares in the company, valued at approximately $6,596,650.94. The disclosure for this sale can be found here. Over the last quarter, insiders have sold 148,277 shares of company stock valued at $56,803,711. Insiders own 4.80% of the company’s stock.

Analysts Set New Price Targets

MDB has been the topic of a number of recent analyst reports. TheStreet raised MongoDB from a “d+” rating to a “c-” rating in a research note on Friday, December 1st. Wells Fargo & Company initiated coverage on MongoDB in a research note on Thursday, November 16th. They issued an “overweight” rating and a $500.00 price objective on the stock. Piper Sandler lifted their price objective on MongoDB from $425.00 to $500.00 and gave the stock an “overweight” rating in a research note on Wednesday, December 6th. Capital One Financial upgraded MongoDB from an “equal weight” rating to an “overweight” rating and set a $427.00 target price for the company in a report on Wednesday, November 8th. Finally, Royal Bank of Canada lifted their target price on MongoDB from $445.00 to $475.00 and gave the stock an “outperform” rating in a report on Wednesday, December 6th. One equities research analyst has rated the stock with a sell rating, three have assigned a hold rating and twenty-one have issued a buy rating to the company’s stock. Based on data from MarketBeat, the company currently has an average rating of “Moderate Buy” and a consensus price target of $430.41.

Get Our Latest Research Report on MongoDB

MongoDB Company Profile

(Free Report)

MongoDB, Inc provides general purpose database platform worldwide. The company offers 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-premise, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

See Also

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

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

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