# Choosing a Database Without Guessing

A few years ago our core jobs took 24 to 48 hours to run. Reports, scoring runs, the heavy work. By the time a job finished, the data had moved on.

I was the Chief Technology Officer (CTO) in the credit monitoring space, and the database decision was mine. This is how we made it. No guessing.

## Step 1: Write down the real workload

Not the workload we wished we had. The real one: over 7 million queries a month, 10,000 clients, and credit data that could never sit in a cache. Credit data was pulled direct from the database every time, for compliance reasons. Any candidate that needed caching to survive was out.

## Step 2: Trial the candidates honestly

We evaluated [Snowflake](https://www.snowflake.com) directly and trialed [Algolia](https://www.algolia.com), [Elasticsearch](https://www.elastic.co), MySQL, and [Meilisearch](https://www.meilisearch.com). Every one of them is good software. Most of them failed on fit: a new query dialect, a rewrite of working Laravel code, or a bill that grew faster than the value.

[SingleStore](https://www.singlestore.com) fit. It spoke MySQL, it worked with Laravel, and it held the analytical and transactional load in one system.

## Step 3: Simulate before you commit

We built fuzzed simulations with fake data at production volume and ran the real queries against them. Trust but verify is my whole career. A vendor demo is a story. A simulation is evidence.

## Step 4: Cut over with zero downtime

We queued incoming requests, swapped the database underneath, then replayed the queue. Nothing dropped. Nobody outside the team noticed a thing.

## The result

Jobs that took 24 to 48 hours finished in 15 minutes. Throughput went from 60 to 1,000 requests per minute. Same team. Same code, mostly. Just the right database under it.

Simulate first. Cut over once.