Choosing the right cloud database

The wrong database choice does not announce itself on day one. It shows up six months later, when your query times have doubled, your ops team is patching what should be a managed service, or your analytics pipeline grinds to a halt because you are running columnar workloads through a row-store. By then, migrating is painful and expensive.

This guide walks you through the cloud database selection process: what questions to ask, what trade-offs to make, and which engine fits which workload. We will walk through the major database categories and map them to OVHcloud®'s managed database and analytics portfolio.

The first question most teams get wrong

The instinct when starting a new project is to pick the database you already know:

• PostgreSQL® if you are a backend developer, 
• MongoDB® if you are in a startup, 
• MySQL® if you have been around long enough to have opinions about MyISAM. 

That familiarity bias is not always wrong, but it stops being acceptable when your workload fundamentally does not fit the model.
The right starting question is not 'what database do I know?' It is 'what does my data look like, and how will I access it?' From that, everything else follows: how you structure data, what consistency promises you need, how you scale, and what you pay.

A framework for the decision

Before touching a console, answer these four questions:

• What shape is your data? Structured rows with fixed schemas, unstructured documents with flexible fields, key-value pairs, semi-structured event streams, time series? Data shape narrows the field dramatically.
• What are your access patterns? Transactional reads and writes (OLTP), complex analytical queries (OLAP), full-text search, pub-sub messaging, real-time caching, or AI-powered vector search? A database optimized for writes will underperform on analytical scans and vice versa.
• What are your consistency and latency requirements?  Does every transaction need to complete fully and correctly before your application moves on, or can parts of your system catch up moments later? Can your data sync across servers with a short delay if it means handling more users or locations at once? Do your users need responses in a few milliseconds or less, or is a slightly longer wait acceptable?
• Who runs it? Self-managing a database cluster is a real cost: patching, failover configuration, backup strategies, and monitoring. A fully managed DBaaS trades some control for operational simplicity. For most teams, that is the right trade.

Decision tree: OVHcloud database selector

Key questions to ask before choosing a managed database

Choosing a managed database service is not just a technical decision. It also involves infrastructure strategy, compliance obligations, and operational risk tolerance. Here are the critical dimensions to evaluate:

Scalability

Will your dataset grow by 10x in two years? Will your traffic spike 50x on a product launch? Two forms of scalability matter: vertical scaling (bigger instance, more RAM) and horizontal scaling (more nodes, distributed load). Relational engines like PostgreSQL and MySQL scale vertically very well, but horizontal sharding requires architectural effort. Document stores like MongoDB and columnar engines like ClickHouse are designed for horizontal scale from the ground up. Kafka scales horizontally by design: adding partitions distributes throughput across a larger cluster. When evaluating a managed service, check not just the current plan but the upgrade path.

Resilience and availability

What is the cost of downtime? For a payment service, even seconds matter. For an internal analytics dashboard, an hour is acceptable. Assess replication topology (how many replicas, across which zones), failover behavior (automatic or manual, and how long it takes), and backup strategy (frequency, retention, and restore time). OVHcloud managed databases include automated backups and configurable high availability, but you need to understand what SLA tier your workload requires and verify the service matches it. Some OVHcloud regions also offer multi-zone replication (3 Availability Zones to be exact), which enables automatic failover and the strongest resilience (SLAs of up to 99.99%).

Latency

What response time does your application need? A transactional checkout flow cannot tolerate seconds of delay, while a nightly reporting job can. Distinguish between read latency (how fast a single record comes back), write latency (how quickly a commit is acknowledged), and query latency (how long complex joins or aggregations take). In-memory engines like Valkey deliver sub-millisecond reads. Columnar engines like ClickHouse are fast at aggregations but slower on individual record lookups. Match the engine to the latency profile of your dominant access pattern, not an average.

Data residency and compliance

Where is your data physically stored, and does that matter to you legally? On the one hand, the US Cloud Act allows greater data access rights to US public agencies. On the other, European regulations such as GDPR impose strict requirements on personal data transfers and who can access it. US-based cloud providers may be subject to legal frameworks (such as the Coud Act) that can introduce additional compliance considerations for US organizations handling sensitive data. 

Operational overhead and managed vs self-hosted

The managed versus self-hosted decision is often framed as a cost question when it is really a capability question. Running your own PostgreSQL cluster means owning version upgrades, vacuuming, failover configuration, backup testing, connection pooling, and monitoring. Managed DBaaS absorbs all of this. The real question is whether your team has the expertise and bandwidth to do it well, and whether that is a better use of their time than building a product.

The database categories, explained

Quick reference: OVHcloud database selector

Relational databases: when structure is your friend

Relational databases are the default choice for a reason. When your data has clear relationships, users have orders, orders have line items, products belong to categories, a relational model enforces that structure, prevents inconsistency, and lets you express complex queries in SQL. Add ACID transactions, and you have a foundation for anything that touches money, user state, or anything where 'we wrote it, so it exists' must be a guarantee.

AI and vector search: PostgreSQL supports vector embeddings natively via the pgvector extension, making it a strong choice for AI-powered applications that combine structured data with semantic similarity search, such as retrieval-augmented generation (RAG), product recommendations, and image search. This allows teams to consolidate transactional and vector workloads within a single database instead of introducing a separate vector database.

PostgreSQL is the right answer when you need power. JSON support, full-text search, geospatial queries via PostGIS, advanced indexing strategies, window functions, materialized views, and pgvector for AI workloads: PostgreSQL is where you go when SQL is not quite enough, but you do not want to abandon the relational model. It is also the engine of choice for workloads with mixed access patterns, transactional writes and non-trivial read queries on the same dataset. OVHcloud's managed PostgreSQL removes the cluster administration overhead, giving you the engine's full capability without the ops burden.

Do not reach for PostgreSQL when your workload is purely high-throughput key lookups, simple caching, or event streaming. PostgreSQL is a precision instrument - if you are storing session tokens, rate-limit counters, or append-only event logs, you are paying for a sophisticated query planner you will never invoke.

MySQL is the right answer when you need consistent simplicity at scale. The majority of web applications, content platforms, e-commerce backends, SaaS products, are served well by MySQL. It is fast on standard OLTP workloads, has mature tooling, and your team almost certainly knows it already. If your query patterns are straightforward and you are optimizing for time-to-production, MySQL on OVHcloud is the pragmatic choice.

Do not use MySQL, however, when your queries are growing beyond straightforward CRUD: complex JOIN chains across large datasets, or heavy querying inside JSON documents, where PostgreSQL’s JSONB and indexing options go further. It is also a weaker fit for AI and advanced spatial workloads: community MySQL can store vector embeddings but lacks native similarity search, and while it supports core geospatial types and indexes, PostgreSQL with PostGIS offers a far deeper spatial toolset. The moment your team starts writing queries that MySQL’s optimizer consistently mishandles, or adding middleware to compensate for what the database cannot express natively, you have outgrown it.

Document databases: flexibility without chaos

Not every problem fits neatly into rows and columns. Product catalogs with wildly varying attributes, user profiles with optional nested data, CMS content that evolves with the product: these are places where a rigid schema fights you instead of helping you.

Document databases store data as JSON-like documents, allowing schema flexibility at the individual record level. The trade-off is that you lose enforced relationships and the expressive power of SQL joins. The gain is agility during rapid development and a natural fit for hierarchical data.

AI and vector search: MongoDB supports vector search natively as of recent versions, allowing you to store vector embeddings alongside documents and run approximate nearest-neighbor (ANN) queries within the same database. This makes it well suited for AI applications where semantic search, personalization, or recommendation logic operates on the same data as standard application queries.

MongoDB is the mature leader here. Its query language is capable, its aggregation pipeline handles complex data transformations, and it scales horizontally via sharding when your dataset outgrows a single node. It is a strong fit for applications where the data model evolves quickly: early-stage products, content-heavy platforms, and personalization engines. OVHcloud's managed MongoDB lets you focus on that iteration rather than replica set management.

One caveat worth stating plainly: MongoDB is frequently misused as a default because it 'does not need a schema.' That is not a design virtue. Production MongoDB requires disciplined data modelling. Use it because your data is genuinely document-shaped, not because you want to skip schema design.

In-memory stores: when latency is the product

Some workloads cannot afford the round-trip to disk. Session management, leaderboards, rate limiting, feature flags, and real-time counters: these need sub-millisecond response times, and they need to sustain that at high concurrency. In-memory stores keep the entire dataset in RAM, which makes them extremely fast and also the wrong place for your system of record.

Valkey is OVHcloud's managed in-memory store, built on Valkey: the open-source fork of the famous Redis engine, created after Redis changed its license in 2024. Valkey maintains full protocol compatibility with Redis while remaining under an open-source license, so existing Redis clients and tooling work without modification. It supports rich data structures, strings, hashes, sorted sets, streams, bitmaps, and is the standard answer for caching layers, session stores, and pub-sub at lower throughput. If your application currently has a performance problem that boils down to 'we are hitting the database too often for data that does not change much,' Valkey on OVHcloud is the fix.

On the other hand, Valkey should not be your system of record. RAM is volatile, eviction policies are not a backup strategy. If the data absolutely must survive a restart, a power cut, or a failed node, it belongs in a durable store. Valkey is the right answer for the data you can afford to lose or rebuild. The moment you cannot afford to lose it; you have picked the wrong tool.

Event streaming: data in motion

Kafka is not a database but a message broker: it does not store data for querying; it moves it between producers and consumers. It becomes particularly relevant when it feeds an analytical engine like ClickHouse: Kafka absorbs and distributes high-throughput event streams, ClickHouse ingests them for real-time aggregation. This combination is what makes use cases like fraud detection or live activity monitoring possible. OVHcloud's managed Kafka still matters if your architecture genuinely needs to decouple high-throughput microservices — but if the goal is mainly to feed an analytics layer, ClickHouse is the piece to lead with. Careful though, as Kafka is operationally non-trivial even managed, and it is the wrong choice when your "stream" is a handful of events per minute, when consumers are tightly coupled and synchronous by design, or when you need request/response semantics. If what you actually need is a task queue, a webhook, or a simple pub-sub between two services, Kafka is the equivalent of a sledgehammer.

Analytical databases: queries at scale

Operational databases are optimized for transactional workloads: fast point reads and writes on individual records. They are not designed for the kind of queries that ask, 'aggregate every order from the last 90 days, grouped by region and product category.' Running that against a transactional store means full table scans, enormous memory pressure, and a slow query that competes with production traffic.

Analytical engines use columnar storage, which stores each field contiguously on disk. This makes full-column scans dramatically faster and compression ratios much higher: exactly what you need for aggregation at scale.

ClickHouse is the right choice for real-time analytics on large datasets. It ingests high-volume event data and returns aggregation queries in milliseconds, even on billions of rows. It is the engine behind many internal BI platforms, product analytics tools, and observability backends. If your team is running complex GROUP BY queries against a production PostgreSQL and noticing it, ClickHouse is the purpose-built answer.

It may be obvious from what was just described, but you should not use ClickHouse for transactional workloads. It is not designed for high-frequency point updates, row-level deletes, or concurrent writes from many sources. ClickHouse is also the wrong choice when your dataset is small enough that a PostgreSQL query with a good index returns in under 50ms. At that scale, you are adding infrastructure complexity in exchange for no meaningful performance gain.

Search and log analytics: finding needles in haystacks

Search is a different access pattern again. Keyword queries, fuzzy matching, relevance ranking, faceted filtering: these are operations that SQL LIKE clauses handle badly and document scans handle worse.

OpenSearch is the open-source engine for full-text search and log analytics. It excels at indexing large volumes of semi-structured data and returning ranked results quickly. It is the standard backend for application log aggregation, security event analysis (SIEM), and user-facing search features. OpenSearch also supports k-NN vector search, making it increasingly relevant for AI-assisted log analysis and semantic document retrieval. Pair it with a transactional database: PostgreSQL or MySQL owns the system of record, OpenSearch owns the search index.

Do not use OpenSearch as your primary datastore. Its index is designed to be built from a source of truth, not to be one. Teams that route all application writes through OpenSearch because "it also stores the document" discover this the hard way when an index refresh lag causes a user to not find the record they just created.

Object Storage: the foundation for retention and recovery

While not a database, Object Storage plays an important role in modern data architecture. Backups, archives, machine learning datasets, analytical exports, logs, and historical event data are often better suited to durable object storage than an operational database. S3™-compatible Object Storage complements managed databases by providing cost-effective long-term retention, disaster recovery support, and a foundation for data lake architecture. Many organizations combine operational databases with Object Storage to separate active workloads from archival data while maintaining accessibility when needed.

Common architecture patterns

Most real-world applications are not one database. They are a composition of two or three, each handling the workload it is suited for. Here are the patterns that appear most often:

• The standard web stack: PostgreSQL or MySQL as the primary data store, Valkey as a caching layer in front of it. The database owns truth; Valkey absorbs read volume. This handles the majority of web application scale requirements without exotic infrastructure.
• The AI-augmented application: PostgreSQL with pgvector (or MongoDB with vector search) as the primary store, handling both structured queries and semantic similarity search in one engine. For teams that need semantic search alongside full-text and log search, OpenSearch's k-NN plugin offers an alternative path to vector search, particularly when the workload is search-first rather than transaction-first. This pattern is emerging as the default for LLM-powered features: your application data and your vector embeddings live in the same system, reducing synchronization complexity.
• Real-time analytics at scale: ClickHouse as the analytical engine at the center of the pattern, ingesting high-volume event data for millisecond-level aggregations. When ingestion volume requires decoupling producers from the analytical store, Kafka sits upstream as the event bus feeding ClickHouse continuously. This combination powers use cases like live dashboards, fraud detection, and product analytics on billions of events — the analytical database does the heavy lifting; the event bus is there to feed it reliably at scale.
• The search-augmented application: PostgreSQL as the source of truth, OpenSearch as the search index. Changes to PostgreSQL are synced to OpenSearch via change-data-capture or application-level writes. Users get fast, relevant search; the database maintains integrity.

What OVHcloud adds is the operational layer: automated backups, high availability configurations, monitoring integration, and European data residency for teams with compliance requirements that may rule out US-based hyperscalers. You get the flexibility of open source without the overhead of self-management, and the legal certainty of a European provider for the most sensitive workloads.

Explore OVHcloud's full managed database portfolio at us.ovhcloud.com/public-cloud/databases/.

OVHcloud® is a registered trademark of OVH SAS. PostgreSQL® is a registered trademark of the PostgreSQL Community Association of Canada. MongoDB® is a registered trademark of MongoDB, Inc. MySQL® is a registered trademark of Oracle and/or its affiliates. Valkey® is a registered trademark of LF Projects, LLC. Redis® is a registered trademark of Redis Ltd. ClickHouse® is a registered trademark of ClickHouse, Inc. OpenSearch® is a registered trademark of The Linux Foundation. Kafka® is a registered trademark of The Apache Software Foundation. SQL Server® is a registered trademark of Microsoft Corporation. Oracle® is a registered trademark of Oracle International Corporation. S3™ is a trademark of Amazon.com, Inc. or its affiliates.

Ready to Get started?

Contact us