Operations | Monitoring | ITSM | DevOps | Cloud

I’ve been building apps with SQL Server for years. Everything worked well until I started dealing with sensor data, stock trade volume, and IoT telemetry. As the volume of time-stamped records grew into the millions, I saw relational databases struggling with workloads they weren’t designed for. That’s when I explored time series databases. The performance improvements were significant, but what surprised me was the mental shift required.

VictoriaMetrics Cloud continues to evolve as the most efficient, scalable and open platform in the observability landscape. In our last Q1 update blogpost, we shared new features such as seamless OpenTelemetry integrations, new Organizations support, and improvements in the Explore UI and APIs. This time we wanted to take a minute to showcase how we’re taking the interoperability journey very seriously. Integrations in VictoriaMetrics Cloud Haven’t tried VictoriaMetrics Cloud yet?

We’re excited to announce the release of SQL Prompt Version 11.0. SQL Prompt Version 11.0 adds support for SQL Server Management Studio 21 (SSMS 21) and includes compatibility with Azure Synapse Dedicated SQL Pools—building on our existing support for Azure Synapse Serverless SQL Pools. Read on to find out more about this new support along with other recent improvements to SQL Prompt.

This discussion is a part of the Basic Series serving as the starting point to quickly get you started with VictoriaMetrics. vmagent is a lightweight metrics collection agent that acts as a bridge between your applications and monitoring storage systems like VictoriaMetrics.

Traditional databases store data in structured tables, whereas NoSQL (non-SQL) databases use more flexible, non-tabular storage methods. NoSQL databases can store a wider range of data types, including document stores, wide columns, key-value stores, and graphs. These databases first emerged in the late 2000s to support massive horizontal scaling and high-throughput workloads for web applications.

Most databases were built for a slower world, one where data waited, systems pulled, and answers came later. But today, data flows. It triggers real-time decisions, powers models in motion, and spans every cloud layer. This shift demands a different kind of database—one built to execute, not just store. Microsoft has answered that call with SQL Server 2025.

Data is the lifeblood of businesses the world over, from the smallest startup to the largest enterprise. Making sure that it’s available when you need it, secured for authorized use, and recoverable from faults is vital to operating data platforms, no matter where your business is on its cloud journey. This can only be achieved by putting the right data into the hands of the right people, in a timely way, to make the right decisions about how to manage that platform effectively.

In a world where database management keeps evolving, following database design best practices is crucial to ensure that your database application keeps performing efficiently. A well-designed database creates a thoughtful relationship between tables and schemas. It enhances application performance, making it work faster, and scales effortlessly. On the other hand, if your database is poorly designed, the application is prone to slow performance and scalability issues.