SSD vs NAS vs Cloud Storage for Photographers

Choose storage by role before choosing a device

An SSD, a NAS and cloud storage describe different parts of a system. SSD is a storage technology, NAS is network-attached storage, and cloud storage is a remotely provided service. A NAS may contain hard drives or SSDs; a cloud service may sit behind software that presents files, backups or objects. They are not three mutually exclusive replacements for one another.

Separate four jobs: active project storage, shared access, archive storage and independent recovery. One device may serve more than one role, but naming those roles reveals the compromises. A fast working disk does not automatically preserve earlier versions. A large archive does not automatically make tomorrow’s job accessible without a network.

This guide compares architectures for photographers rather than ranking current products. It uses hypothetical capacities and workflows, with no invented drive benchmarks, quoted prices or universal lifespan claims. For the detailed recovery procedure around the architecture, use the professional photo-library backup guide.

Begin with practical requirements: where you work, who needs access, which applications own the catalogs, how much material changes each week, and how quickly a failed working system must be replaced. Those answers matter more than a connection label on a box.

Scroll across to read all columns.

Understand what SSDs and hard drives change

Sandisk’s SSD/HDD explanation distinguishes solid-state storage from a hard drive’s moving mechanical parts. That is a useful basis for comparing access behavior, but not a reliability guarantee or a promise that every external SSD outperforms every other configuration in every task.

For active editing, consider how often the application accesses many small records, loads source images and writes temporary or working documents. Catalog operations, source decoding and final output can stress different parts of the computer. A quicker source disk will not remove a processor-bound RAW rendering stage or a network bottleneck elsewhere.

Internal storage is convenient because the working path is usually available whenever the computer is on. Capacity may also be needed by the operating system, applications, caches and temporary exports. A catalog that fits today can still run into workspace pressure when a large job creates previews or layered masters.

External SSDs can separate working jobs from internal capacity and make a portable setup practical. Check the entire path: drive, enclosure, connection, cable, hub and power. A compatible plug does not establish the negotiated transfer mode or sustained performance. Secure the connection during an import or save; portability does not make an interrupted write harmless.

Hard drives remain worth evaluating where substantial capacity and the actual acquisition cost suit an archive or recovery role. Measure your own task rather than assuming a large capacity or rotational specification explains the whole experience. A mostly sequential copy and repeated browsing of many small files are different workloads.

Neither type should become the only copy of valuable work. An SSD’s lack of moving parts does not protect against deletion, controller failure, theft or a wrong destination chosen during a format. A quiet drive is not evidence of a healthy archive.

Treat a NAS as a small managed system

A NAS makes storage available through the network. Its value can include shared folders, centrally administered access and scheduled protection tasks. It also introduces dependencies: the network path, permissions, server software, power, available capacity and the applications using the files.

Distinguish shared originals from a shared live catalog. Several editors may be allowed to read the same image archive while their catalog databases require another arrangement. Follow each application’s explicit network and multi-user rules. A file share that opens a JPEG does not establish safe simultaneous writing to an application database.

Check how paths appear to each machine and account. Two users may mount the same share differently. A saved path, a familiar server name and an existing session do not prove that the next person has the correct permission or that the catalog will resolve its references after a restart.

Administration belongs in the cost and recovery plan. Record who maintains updates, monitors alerts, manages accounts and knows how to recover if the enclosure or storage pool becomes unavailable. A studio should be able to identify that person without relying on the one workstation that just failed.

Synology’s NAS backup guidance distinguishes local versions from copies at another destination and warns that local protection can still be affected by RAID or drive failures. Its listed tools have different destinations and capabilities. Evaluate the specific model and setup; the word NAS does not certify an independent backup.

For remote work, use a documented and maintained access configuration appropriate to the service and material. Check authentication, allowed users and the recovery route before relying on access from another location. Avoid making remote connectivity a prerequisite for every deadline unless you have tested the corresponding outage plan.

Identify which cloud service you are actually using

Cloud file synchronization, cloud backup, hosted galleries and object storage solve different problems. A synchronized folder can be convenient for collaboration. A backup service should provide a defined recovery process. A gallery delivers a particular rendered set. Object storage holds items through a service interface, usually accessed by another tool.

Ask whether full source files are local, downloaded on demand or absent from the current machine. A placeholder can preserve a filename and thumbnail without containing the full image bytes your editor needs. Test offline access to representative originals before treating a synchronized library as an offline archive.

A hosted gallery is not automatically a backup of camera originals, catalogs and editable masters. It may contain only delivered JPEGs or transformed previews. An object-storage bucket is not automatically an ordinary drive that every Mac catalog application can read. The client software and its behavior are part of the decision.

Read the service’s retention, deletion, versioning and recovery terms. Determine how a mistaken overwrite or a propagated deletion is handled and which account can remove the recovery copies. A successful upload gives useful evidence about transfer completion, but it does not answer every future recovery question.

Keep recovery access independent enough to survive loss of the working computer. Record the account owner, secure credential recovery process and any required encryption keys. A cloud copy that cannot be accessed after the only signed-in laptop disappears is not an adequate plan for that failure.

Separate availability, synchronization and backup

Redundancy can help keep a system available through certain component failures. Synchronization can keep selected locations aligned. A backup should offer recovery of the required data and, where needed, an earlier version. Their benefits overlap, but none of those labels establishes the others.

RAID is not an independent backup. A usable array can faithfully preserve an accidental deletion or unwanted edit; an enclosure, account or administrative action can affect multiple member disks. Treat its resilience as part of availability, then plan recovery outside the same relevant failure domain.

A second disk beside the first protects against some failures and shares others. A remote copy protects against some location failures and introduces transfer and account dependencies. Write down what a copy is expected to survive rather than counting locations without checking their relationships.

Active workOriginals, current catalog and editable documents

Local recoverySeparate, checked versions for practical restoration

Off-site recoveryA copy outside the working location’s failure domain

Availability questionCan the next working task continue?

History questionCan an earlier correct version be retrieved?

Independence questionCan one event compromise every copy?

Keep restore checks separate from copying checks. An application can report a completed job while a required source folder was excluded. A file can copy correctly while its intended editor lacks a necessary sidecar or catalog record. The backup guide provides a fuller inventory and a safe alternate-destination restoration exercise.

Budget for the whole job, not just camera files

Capacity planning begins with measured data roles. Count originals, sidecars, catalog files, working masters, delivered files and temporary workspace. Add the actual retention behavior of each backup or snapshot system. A storage purchase should accommodate the job you produce, not just the card you bring home.

For an illustrative workload, suppose camera originals occupy 400 GB, working masters 120 GB, outputs 30 GB and current previews or temporary material 20 GB. That is 570 GB before other applications, earlier versions, future jobs and any free-space requirement. These are invented planning inputs, not a camera estimate, a product specification or a recommended disk size.

Use usable capacity for the selected configuration, not simply the sum of labels on every installed disk. RAID layout, filesystem overhead, reserved capacity and snapshots can affect what is available. Ask the system’s own management tools for the relevant figures and preserve room for the actual working process.

Track growth from closed jobs as well as active ones. A studio that deletes temporary exports may still retain large editable masters and delivery revisions. Forecast from several real completed jobs and a realistic future workload, then review the estimate periodically instead of treating it as permanent.

Scroll across to read all columns.

Measure the actual workflow and understand the limiting stage

Separate connection bandwidth from end-to-end task time. A port label describes a connection capability, not the measured speed of your complete job. The drive, enclosure, cable, network, source layout, encryption, application and image decoding can all affect what you experience.

Units also matter. Bits per second and bytes per second are different quantities; there are eight bits in a byte. A quoted network rate cannot be compared directly with a file-copy rate in megabytes per second without considering units and overhead. Keep decimal and binary capacity conventions clear in a written estimate.

A simple transfer estimate is data size divided by an assumed sustained rate. Use it as an idealized planning calculation, then measure the actual task. Many small files, metadata work, server contention, cache state and the slowest source or destination can change the result. An internet upload estimate is not a restoration-time guarantee.

1. Name the task. For example, import a representative folder, reopen a catalog, load detail or recover a closed job.
2. Record the setup. Note source and destination, connection, application version and whether caches are warm.
3. Use representative material. Include real file types, sizes and folder patterns from a safely backed-up sample.
4. Time the complete result. Distinguish copying, cataloging, preview preparation and full source rendering.
5. Check correctness. A quick run that omitted files is not an improvement.
6. Change one factor. Compare the same task before attributing the difference to a device category.

Do not extrapolate a one-file test into unlimited catalog or multi-user performance. A NAS may behave differently when another person is writing large masters. Cloud recovery may be constrained by retrieval procedures or local destination capacity even when download bandwidth is adequate.

Example architecture: a photographer working alone

Consider a hypothetical photographer who edits on one laptop and needs selected jobs available away from the studio. The active catalog can remain in a supported local location, with working originals and masters on local or attached storage chosen for the measured workload. Keep a documented path arrangement so an external drive does not become an unexplained dependency.

Use a separate local recovery destination for completed copies and appropriate version history. Maintain an independently recoverable off-site set through a service or rotated storage process you have validated. Record when the off-site copy is incomplete; a large job still uploading is a visible coverage gap, not a fully protected archive.

Before travel, identify the actual originals and editing documents needed offline and verify that they open without the network. Keep the catalog’s organizational decisions protected as they change during the trip. A copy made before culling begins may preserve every original and none of the later selection.

This architecture does not require a NAS merely because one is available. Add shared storage when its actual benefit justifies the administration, connectivity and recovery requirements. Start with a system that you can explain and restore.

Example architecture: a small studio sharing an archive

Now consider a hypothetical studio with two editing stations and one person responsible for archive administration. The studio may use a NAS for shared source access or closed jobs while retaining application catalogs in locations explicitly supported by each editor. Shared images and shared databases remain separate decisions.

Give each active job a clear owner and a handoff record. If one person creates a retouching master, the next person should know its location and accepted version. Avoid two workstations silently producing competing files under the same final name. Use permissions and a reviewed workflow to make responsibilities legible.

Plan protection for the NAS and the workstations. A source archive can be protected while current catalogs remain only on a workstation, or the reverse. Include the actual local working areas in the coverage record and test a recovery that needs both parts.

Synology’s documentation lists external, remote-NAS and cloud backup routes with differing capabilities. Treat those as options to investigate for a supported system, not interchangeable assurances. A local snapshot is useful history and still needs a plan for loss of the storage system or location.

Test a realistic concurrency scenario before depending on shared access under deadline. Record the result without generalizing it into a universal NAS benchmark. Also test what happens when the server is temporarily unavailable: which tasks can continue locally, which files are safely staged and how later changes are reconciled.

Keep catalog references and local permissions understandable

A referenced-file catalog records where originals can be reached. Moving a job between an SSD and a server changes a storage relationship; copying bytes does not automatically update every application reference. Keep the folder tree, sidecars and old/new mapping until the replacement arrangement has been checked.

Reviewed Lightbox Pro 0.1.2 (62) uses local catalogs and has an accepted chosen-folder reconnection workflow with explicit review. Its accepted reconnection scope is local storage; network, provider-managed and cloud reconnection are deferred. This does not establish universal NAS behavior in either direction. Do not infer supported live database sharing or automatic cloud hydration.

Mac/account-specific folder access may need reselection on another machine. Missing previews, unavailable originals and permission failures are different states. Rebuild refreshes known references; it does not discover a moved source. Use the missing-photo decision tree before making broad changes to an archive.

Lightbox Pro’s persistent previews can support reduced-detail browsing when prepared originals are unavailable. They are not an offline copy of the full source and do not establish usable critical RAW detail. Plan offline jobs around the actual files and editor records needed, not only the thumbnails currently visible.

Include administration, recovery and access in the cost

Compare total cost over the intended use period rather than one purchase price or one monthly headline. Include usable capacity, enclosure or server, connection upgrades, power, replacement planning, support time and independent protection. Avoid assuming that the least expensive initial storage produces the least expensive recovery.

For cloud services, examine storage, transfer, retention and request terms for the actual workflow. Backblaze’s transaction schedule illustrates that operations are itemized separately from stored capacity. It does not mean every action incurs a charge. Check current provider terms and estimate your own retrieval scenario; no price is quoted here.

Control who can read, change or delete each working and recovery location. Separate ordinary collaboration access from administrative recovery powers where the system supports it. Keep account recovery and any encryption keys through an appropriate secure process. Encryption without a recoverable key can make an otherwise intact backup unusable.

Maintain the software and inspect alerts. A storage system with an owner, a review date and a practiced recovery procedure is easier to trust than one whose last configuration nobody remembers. Changes to accounts, service plans or folders should trigger a check of protection coverage.

Prepare the next action before a failure occurs

If a drive or share disappears, first establish whether the problem is connection, mounting, access, capacity or missing data. Preserve the working record and error details. Do not format a destination, initialize an unfamiliar volume or overwrite every alternative merely to remove a warning.

Identify the last independently verified recovery copy and restore a representative set to a separate location using a method whose destination behavior you understand. Check source identity, catalog organization, edits and output. For a failing device with the only surviving copy, repeated experimentation can reduce your options; preserve it and assess an appropriate recovery route.

Finish the plan by naming the recovery owner, the locations, required credentials and the acceptance test. Then practice a safe portion of it and record the result. The best storage architecture for a particular photographer is the one that meets the workload while keeping the files, their decisions and the recovery path understandable.