Non-relational data on Azure

Azure Storage in one view

An Azure Storage account is a namespace that can hold several data services. A general-purpose v2 account supports blobs, files, queues and tables.

Common storage features: encryption at rest by default, Microsoft Entra ID and shared access signatures (SAS) and account keys for access, private endpoints, and a choice of redundancy.

Redundancy options

The secondary region copy is asynchronous.

Azure Blob storage

Blob storage holds massive amounts of unstructured data: documents, images, video, logs, backups.

Structure

Storage account → container → blob. Containers are flat; folders are simulated with / in names unless the hierarchical namespace is enabled.

Blob types

Access tiers

• Lifecycle management policies move blobs between tiers or delete them automatically based on age or last access.
• Other features: soft delete, versioning, snapshots, immutable (WORM) storage for compliance, static website hosting, change feed, object replication.

Azure Data Lake Storage Gen2

Blob storage with hierarchical namespace enabled. Real directories with atomic rename and POSIX-style ACLs, optimised for big-data analytics. Fabric, Synapse, Databricks and HDInsight all read it through the ABFS driver. Pick it when the question says “data lake” or “analytics on files”.

Azure Files

Azure Files provides fully managed file shares in the cloud.

• Protocols: SMB (Windows, macOS, Linux) and NFS (Linux). Also REST.
• Mount concurrently from many VMs and on-premises machines (over a VPN or ExpressRoute, or directly over the internet with SMB 3).
• Azure File Sync caches a share on Windows Server for fast local access and tiering.
• Use for lift and shift of applications that expect a file share, shared configuration or tools, and replacing on-premises file servers.
• Supports identity-based access (Microsoft Entra ID, AD DS), snapshots, and Standard (HDD or SSD) and Premium (SSD) performance.

Blob versus Files: blobs are accessed by URL as objects, ideal for web content and analytics; Files are mounted as a drive and used by applications that need a path and file-system semantics.

Azure Table storage

Table storage is a NoSQL key-value / key-attribute store for structured, non-relational data.

• Stores entities (rows) in tables; no fixed schema, so entities in one table can have different properties.
• Every entity has a PartitionKey and a RowKey; together they are the unique primary key. Items with the same PartitionKey are stored together and queries on key are fast.
• No joins, foreign keys or complex queries; secondary indexes aren’t supported.
• Very low cost, scales to terabytes; good for flexible datasets such as user data, address books, device information.
• Azure Cosmos DB for Table is the premium option with the same API plus global distribution, automatic indexing on every property and guaranteed low latency.

Azure Cosmos DB

Azure Cosmos DB is Microsoft’s fully managed, globally distributed, multi-model NoSQL database for modern apps.

Why use it

• Single-digit-millisecond reads and writes at the 99th percentile, backed by SLAs on latency, throughput, availability (up to 99.999%) and consistency.
• Elastic, horizontal scale of storage and throughput.
• Turnkey global distribution: add or remove regions with a click, with optional multi-region writes.
• Automatic indexing of all properties without schema or index management.
• Schema-free items (typically JSON).
• Open APIs for existing ecosystems; supports vector search for AI apps.

Typical use cases

• Web, mobile and gaming back ends needing low latency at global scale.
• Retail product catalogues and shopping carts; personalisation.
• IoT and telemetry ingestion.
• Social apps and graph relationship queries.
• Event sourcing and change-feed driven designs; AI apps and RAG with vector search.

APIs

The API chosen at account creation fixes the data model and query language, and can’t be changed later.

Memory aid: NoSQL = JSON documents, MongoDB = MongoDB apps, Cassandra = wide column, Gremlin = graph, Table = key-value.

Throughput and partitioning

• Capacity is measured in Request Units per second (RU/s). A request unit is a normalised cost of CPU, memory and I/O; a point read of a 1 KB item costs 1 RU.
• Throughput modes: provisioned (manual or autoscale), and serverless (pay per RU consumed, for light or bursty dev/test).
• Data is split into logical partitions by a partition key you choose. A good key has many distinct values and spreads requests evenly; a poor key creates a hot partition.

Consistency levels

Five levels trade consistency against latency and availability:

Strong → Bounded staleness → Session (default) → Consistent prefix → Eventual

• Strong: linearizable, always latest write, highest latency.
• Session: a client reads its own writes; the default and most widely used.
• Eventual: lowest latency, reads may lag and be out of order.

Other features

• Change feed exposes an ordered log of inserts and updates for triggering functions or syncing.
• Backup is automatic (periodic or continuous with point-in-time restore).
• Azure Synapse Link / Fabric mirroring replicates Cosmos DB data to analytics stores without affecting transactional performance, for HTAP scenarios.

Cosmos DB versus other stores