As an ISV there are several options when it comes to choice of platform. The developers need to be in favor of the choice or you will get into trouble for sure. But it has to make sense from an economic standpoint as well. From a high level perspective there are three things that drive
In Part IV of this blog series, we dove deeper into the database as the puppeteer, as well as Puppet itself. In this final post, we’ll take a quick look at the “think” client and wrap things by helping you assess which approach makes the most sense for you when choosing the right database and framework for your real-time app.
In Part III of this blog series, we continued to explore some of the key considerations when choosing the right database and framework for your real-time mobile app. Now, let’s dive deeper and take a look at the database as the puppeteer, as well as Puppet itself.
In Parts I and II of this blog series, we presented three possible categories that a typical real-time mobile app falls into, and started to take a look at the design choices for all three kinds of apps. Now, let’s continue to explore some additional considerations when it comes to choosing the right database and framework for your real-time app.
In the first part of this blog series, we kicked things off by taking a look at the three possible categories that a typical real-time app falls into. Now, let’s start to explore the design choices for all three kinds of apps. Quick heads up before we dive deeper – the term “app” used throughout
If you’re a mobile app developer, I imagine you’re constantly feeling the pressure to quickly bring new apps to market and update them faster than ever before. The demand is only ramping up, with no change in pace on the horizon. Like many mobile app developers, you also most likely need a hard-working database behind
In our last post in the Definitive Guide to the Modern Database series, we examined three different trade-offs: In-memory vs. Disk-based; Scale-In vs. Scale-out, Consistent vs. Inconsistent; and SQL vs. NoSQL, “Classical” vs. “Modern.” Today let’s take a look at the final trade-off to consider when selecting a modern database.
In our last post in the Definitive Guide to the Modern Database series, we examined the trade-off of Transactions vs. Analytics. Today let’s take a look at three more trade-offs to consider when selecting a modern database.
When we last discussed a couple of initial trade-offs to keep in mind when choosing a modern database, we explored Human-Generated vs. Others, as well as Structured vs. Unstructured. In this blog post, we’ll dive deeper into a third trade-off to consider.
Data processing is ubiquitous (this should be a surprise to exactly no one). From money transfers to your phone contacts being stored in the cloud, the average consumer unknowingly benefits from data processing daily.
In part one of this two-part blog post, we explored a few things you should consider when choosing a new database, including the purpose of the application, true consistency, and high performance. Part two touches on four additional factors you should keep in mind during your selection process.
When you look at the database market, it’s a virtual jungle out there. Those of us in the industry 15 years ago can look back and remember when we only had the option to use a relational database from Sybase, ORACLE, Microsoft or IBM.
If you have a successful application and it relies upon persistent data then data storage will probably become your bottleneck. There are two main strategies for scaling an application: vertical scaling and horizontal scaling.