The Cost of a Database Choice

The Second Database Begins as One Feature

A SaaS team wants better order search. Support needs to find orders by email address, SKU, shipment status, and fragments from customer notes. The transactional database can answer exact lookups, but flexible text search is slow and awkward. A managed search service appears to solve the problem cleanly.

At the feature level, the proposal is simple: copy order data into a search index and query it. At the production level, the team has proposed a second data system.

Someone must decide which order fields may be copied. The write path must publish changes without losing them. Users need an explicit freshness expectation. Failed indexing needs detection and replay. Deletion and retention rules must reach the index. Access to support notes must remain restricted. Reindexing needs time and capacity. On-call needs to know what degrades when the service is slow. The team must also prevent a convenient search result from becoming an accidental source of truth.

None of these consequences makes the search service a bad choice. Together they reveal its cost shape: what the choice makes cheap, what it makes expensive, who will carry the expense, and which parts will be difficult to change.

Capability is the entrance requirement. A store that cannot preserve the required invariants, serve the read path, meet the durability target, or satisfy retention rules does not qualify. Among the stores that do qualify, the real decision concerns the whole bundle of spend, labor, failure, and future constraint.

Find the Meter

The invoice shows compute, storage, I/O, replicas, backups, support, network egress, licenses, and retained history. Those figures matter, but a monthly total does not explain how the design will age. The first useful question is: which operation becomes the meter?

For the search proposal, several operations might dominate at different times. Every order update creates indexing work. Every copied field increases index size. A changed mapping or analyzer may require a full reindex. A new region may duplicate both storage and data movement. A surge in support queries may demand capacity sized for a brief daily peak rather than the average hour.

Unit economics connects those operations to the business. Estimate cost per order update, per searchable order, per support query, and per full rebuild. Then vary the quantities that are likely to change:

• ten times as many orders;
• a year more retention;
• a second region;
• a large tenant with an unusual query pattern;
• a schema change that touches every indexed document;
• an emergency rebuild while ordinary indexing continues.

The exact currency estimate may be rough. The relationship should not be. If one order update fans out into several derived writes, growth in order activity multiplies work. If a rebuild scans all retained history, retention changes recovery cost as well as storage cost. If the system must hold spare capacity for a burst, average utilization understates the price of the latency target.

This is why “will it scale?” reveals so little. An activity feed that fans out on read and one that fans out on write may both handle the target traffic. The first pays for expensive reads and ranking when popular users are viewed; the second pays for multiplied writes, larger storage, and idempotent retry handling whenever they publish. Scale is not a property bestowed by a product. It is the growth of particular work.

Visible spend is only the first line of the account. The team will also pay in engineering attention: schema and index changes, dashboards, credentials, incident response, restore or rebuild drills, local development, security review, training, and migration machinery. These costs rarely share a billing unit, but they still compete for the same people and calendar.

A New Store Creates a New Operating World

Adding a database class does more than add a runtime. It adds a way of modeling data, a query language or API, failure semantics, capacity limits, security controls, migration tools, dashboards, and recovery procedures. Each environment needs configuration and credentials. Each alert needs an owner. Each unusual behavior needs enough shared knowledge that a page does not depend on finding one expert.

That is the complexity budget behind polyglot persistence. Specialized systems are often justified. A transactional database need not become a poor search engine, stream, warehouse, and time-series store merely to keep the architecture diagram small. But every proposed addition should answer a demanding question:

Which workload requirement can the systems we already operate no longer meet reasonably?

For order search, the answer might be flexible text retrieval with filters and a freshness target under sixty seconds, at a volume that would distort transactional indexes and interfere with checkout. That is evidence. “Search belongs in a search engine” is only a category preference.

The answer must also fit the organization. If the platform team will not support the service, the application team owns its strange alerts and upgrades. If security tooling cannot review its access model, audits acquire manual steps. If only one engineer understands mappings and reindexing, ordinary feature changes gain a staffing dependency. A technically capable system can exceed the operational maturity of the team asked to carry it.

Managed service changes this calculation; it does not end it. The provider may operate machines, replace failed nodes, apply some patches, and expose backup features. The team still owns data modeling, query behavior, capacity choices, credentials, retention policy, cost controls, application-level recovery, and the meaning of a correct restore or rebuild. “The provider has backups” does not establish that the team can recover the right state within the required time.

Before approving the search store, ask for a small amount of operational evidence. Can a second person diagnose indexing lag? Can the team rebuild a production-sized sample and measure how long it takes? Are large mapping changes observable and reversible? Who owns runtime health, the source-to-index contract, access control, deletion propagation, and spend? An unanswered question is not an automatic rejection, but it needs an owner and a cheap experiment—not borrowed confidence.

Failure Modes Belong in the Price

The search store buys flexible retrieval by accepting a derived copy. That exchange changes what can go wrong.

An order may commit while its indexing event is lost. A poison document may block a batch. Consumers may fall behind. A reindex may omit a field or apply a new mapping inconsistently. Search may show a status that is forty seconds old. A support tool may begin allowing corrective action directly from those stale results. Deletion may reach the transactional record but not the index. During an outage, retries may overload both the projection and its source.

The decision should follow each failure to a user or operator consequence. If search is unavailable, can support fall back to exact order lookup? If indexing is delayed, is freshness visible or merely wrong? If customer-facing search omits a recent order, what promise has been broken? If support uses a result to authorize a refund, which authoritative read rechecks the decision? If a rebuild exceeds the recovery window, which workflows remain degraded?

This is design accounting, not pessimism. A database often improves one failure mode while introducing another. A relational store may give the command path strong constraint enforcement while paying in lock contention, migration discipline, and query-plan risk. A search index may give the read path powerful retrieval while paying in staleness, projection repair, and accidental authority. The cost belongs to the choice that creates it.

Governance failures deserve the same treatment. Support notes may contain sensitive data. Search fields must have an access model, an audit story, and a deletion path. Retention rules must address both ordinary indexes and snapshots. Restoring old data can reintroduce information that was deleted after the backup was taken. Regional replication can become a residency decision. For sensitive workloads, these are not forms to complete after architecture; they are behavior the architecture must support.

Dependence Is Specific

Teams often discuss vendor lock-in as if a store were either portable or trapped. Real dependence is more particular. The order-search design may rely on a provider’s query language, ranking behavior, analyzer, change-stream integration, identity controls, snapshot format, regional footprint, or scaling limits. Each dependency can be worthwhile if it buys enough value.

A familiar protocol does not erase these differences. Products that accept similar queries can still differ in transactions, isolation, pagination, indexes, failure behavior, quotas, and operating tools. Portability lives in the exact features and semantics the application adopts, not in the name printed on the API.

Record the dependencies deliberately. Name the provider-specific features the design uses and why. Record the limits that would constrain growth or regional expansion. Keep concrete exit evidence: which authoritative facts can be exported, where replay begins, how results would be validated, and which application contracts assume the current store’s behavior.

This avoids both vendor paranoia and vendor innocence. Refusing valuable managed features in pursuit of imaginary portability can waste engineering effort. Depending on them while writing “we can migrate later” hides the bill.

Design Gravity Makes “Later” Expensive

Once a store enters production, other decisions begin to orbit it. Identifiers leak into APIs. Application code adopts its query model. Workers assume its ordering. Dashboards use its timestamps. Support workflows depend on its indexes. Exports mirror its schema. Runbooks encode its failure modes. Hiring starts favoring people who know it.

Some gravity is desirable. A billing ledger or identity store should not be easy to replace on a whim. The danger is accidental gravity: a provisional side system becomes authoritative because its convenience attracted more responsibilities than anyone intended.

Reversibility is therefore a design property, not a future promise. For the search system, the source of truth can remain in the transactional store. The team can preserve a change history or another complete rebuild source, keep storage-specific identifiers behind service contracts, make index freshness visible, and retain an exact-lookup fallback for critical support work. These choices do not make migration free. They keep a derived system derived.

Reversing a primary store is much harder. Transaction semantics, historical meaning, keys, volume, restore guarantees, and dependent systems all cross the migration boundary. A credible reversal plan must account for export, schema translation, backfill or replay, dual operation, comparison, cutover, and rollback at projected volume.

Keeping every door open forever would produce layers of abstraction that cost more than the risk they insure. Decide which doors need to remain open long enough for evidence to arrive. A rebuildable search index may deserve strong reversibility. A carefully chosen system of record may deserve an explicit long-term commitment.

The Decision Ledger

A decision ledger records the bet as it exists now and the evidence that would reopen it. It is not a scorecard or an approval ceremony. Its rows belong together because a reviewer needs to compare the assumption, burden, owner, trigger, and reversal move at once.

For the order-search proposal, a useful ledger might read:

The value of this ledger is its falsifiability. If normal freshness exceeds sixty seconds, the assumption has failed. If support begins correcting orders from search results, the authority boundary has failed. If no one can rebuild the index inside the recovery window, reversibility has failed. A review date is useful, but observed evidence is the stronger clock.

Compare that with four entries that only sound complete:

• “Chosen because it scales” names neither the work that grows nor its cost.
• “Managed service, so low operations” assigns the provider responsibilities it does not own.
• “Eventual consistency is acceptable” says nothing about what may be stale, for whom, for how long, or with what harm.
• “We can migrate later” omits the data, semantics, validation, cutover, and rollback that a migration consumes.

The ledger should make vague confidence uncomfortable. That discomfort is useful before design gravity hardens.

Run the Review in This Order

Start with the workload fingerprint and invariant register from the preceding chapters. They determine whether the candidate belongs in the room at all. Then ask what measurable value the new store buys over systems the team already operates.

Next, trace the cost shape. Identify the operation that drives marginal spend, the human work that continues after launch, the incident modes the choice introduces, and the governance work required across every copy. Bring evidence where it exists: a volume model, representative queries, a rebuild measurement, a degraded-mode sketch, an access model, or a backfill estimate.

Then examine gravity. Which data model, keys, semantics, APIs, derived systems, and operating procedures will start depending on this choice? Which dependencies are intentional? Which small design moves preserve an exit without building a speculative abstraction layer?

Finally, write owners and review triggers into the ledger. Unknowns are acceptable when their consequence is bounded and someone owns the experiment. Unowned assumptions are merely delayed surprises.

Practice: Write the Regret First

Choose a proposed database, stream, cache, search index, warehouse, or archive. Before naming the product, write the paragraph you would hate to write six months after launch:

We chose this system because ____. We now regret it because ____. The first evidence was ____, but we did not act because ____. Changing course now requires ____.

Use the paragraph to expose the assumption with the greatest downside. Then draft a decision-ledger entry that includes:

• the role of the store and the facts it may treat as authoritative;
• the workload and invariant evidence that makes it attractive now;
• the operation that drives spend and the work that drives toil;
• the incident, compliance, staffing, or migration condition that would reopen the choice;
• a named owner for that signal;
• one concrete reversal move worth making before launch.

Test one uncertain claim cheaply. Run representative queries, rebuild a production-shaped sample, measure an export, rehearse a degraded path, or trace a deletion through every copy. Then decide whether the evidence strengthens the proposal, changes its boundaries, or removes the need for another system.

A database choice deserves more than a feature checklist because it will teach the surrounding system how to behave. The ledger captures that lesson while it can still be revised. The next chapter turns to one of the strongest sources of design gravity: the way a data model makes some queries natural, other queries expensive, and certain facts difficult to move.